I am hoping to keep this one short because it is a simple one. And yet, somehow it becomes a hot debate every time when it is being used. You are not gonna need it.

In the world of agile coaches and broken agile processes, I often hear: We’re going to invest time when it comes to it. Which often ends up in situations where a full rewrite is needed, if we didn’t do some groundwork beforehand. That is why most of them write a book or become LinkedIn influencers while moving from project to project and leaving the old ones to fend for themselves. I think my stand on today’s “agile” is clear and the rant post will be coming at one point. Where I apply some AI to it, to remove all profanity. Left with the title at the end.

Don’t get me wrong, overengineering from get to is not a way to go as well. This is where that preparation work, and experience, comes into play. It is a fine balance of thinking ahead and understanding the trade-off when the toll comes due. And from there, go forward with confidence. You made a concise choice and managed expectations, so there is nothing coming to bite you back. Right, and we all live in Narnia. Yes, easier said than done, especially with the manager thinking that it is “just an if”. This is where the experience comes into play and good team dynamics. Groundwork is doing design upfront, to a reasonable amount. When certain that there will be a need to plugin some new feature in the coming weeks, maybe spending an extra day to make a current one encapsulated behind an interface is better. Or something more sinister, you know your projects and team members.

That is why I believe team dynamics are a really important factor when comes to design upfront. Good review and questioning choices made need to come from both business and developers and balance needs to be struck. Talking from experience, where a feature could have been done in a matter of days in some cases took weeks due to choices made. And where this is most predominant is when it comes to data. If you have never had the pleasure of trying to fix production data, whatever is stored behind it, you don’t know what you are missing. My gray hairs can be mapped to a number of those migrations, easily. Hackathon-level project is not something that you will be thankful for when you can’t afford downtime to just “add this column”.

While there is another spectrum of this. Overengineering. There are a number of projects from my past that started with GoF book implemented. In some cases felt like they had a wheel of fortune to choose which ones to use. Just to keep it interesting and fresh. This is where I think development team experience comes into play. We all started by learning these “best” practices and thinking it is the only way to develop software.

💡 A formal way of documenting a general reusable solution to a design problem in a particular field of expertise.

Sometimes we just see zebras where there are just horses. And we jump a gun. Again, we’re all guilty of this. We just forgot where we started, now that we’re mature and wise. Anyhow, the team needs to understand the balance of usefulness of going in a certain direction. While not being constrained to question choices made, when they’re causing more harm than they’re worth. That is what it means to be agile, in my opinion. Do just the right amount of work at each stage of the project and be ready to accept the changes that will challenge the original assumptions. Or validate them.

There is a popular diagram used out there, very often, to illustrate these tradeoffs. Interestingly named; the project management triangle. Or, cute nickname, triple constraint. Not sure who did it, but I often see it being thrown into my face when talking about tradeoffs on the project.

Project Management Triangle depicting tradeoff between Cost, Time and Quality

And then it says: Pick two. You can’t have it all, which does make sense if you paint it black and white. Then again, as with everything in my posts, I am starting to see that the picture is not always this clear. When last time I had a discussion on this, there was another picture developing in my head, of a sound equalizer. Where each of the knobs will give you a different output. The number of things you can “tune” depends on your project and the outcomes you wish to achieve.

An alterntive to Project Management Triangle that indicates that there are different layers that can impact project and they all depend on project at hand

And you keep adding the parameters that can impact the overall impact of your delivered product. The granularity of these parameters heavily depends on your choices and what impact will have, but this paints the picture. It may sound like this is a tangent and what it has with YAGNI, but when you think about what I wrote about at the start is reflected here. You’re not gonna need this or that. And if the slider on it has an impact on end delivery, then you will know it. As this statement can be applied to any aspect of our development cycle; quality, tests, resilience, etc. Thus, the tangent. That will have it is own post in the future, maybe even combined with one about Agile I am planning to write.

For now, I am leaving you with these closing words. You are not gonna need it, applies heavily. Then again, it is simple math; Document tradeoffs and impacts where this term is being used. Then from those decide the route which suits you best and gets you closer to the outcome you wish to achieve at the end. Don’t be afraid to adjust the sliders along the way as new things show up, that you didn’t have in mind. Just don’t blindly start overengineering or under-engineering, for the sake of: We will figure it out later. There is always time to brainstorm and come up with an attack plan, projects that cost money are not something you’re doing as a hackathon.

Until next time, think if you’re going to need it.