Doug Hieber, Senior Software Architect
January 28, 2016

“You Ain’t Gonna Need It” and is an old extreme programming (XP) term. If you’ve never heard of it before, the author of this blog post explains what it is and how this philosophy keeps Agile developers from over-engineering.


agile post itsMy good friend YAGNI is not a person but a philosophy that we are using as part of our Scrum/Agile development process. It stands for “You Ain’t Gonna Need It” and is an old Extreme Programming term to keep developers from over-engineering the system. Over-engineering results in unnecessary complexity and cost. It delays releases and thereby delays adding value to the business. I’ve even seen it cause projects to fail. YAGNI to the rescue!

In an Agile process, we try to avoid looking too far ahead to prevent building components and frameworks in support of future requirements that may never come. Instead, we build the components and frameworks needed to support the requirements that are approved for the current sprint.

As someone who was raised on the Waterfall and RUP processes, I am frequently tempted to build for the “icebergs” looming on the horizon. This would involve increases in the architectural framework, more elaborate designs and accepting more complexity; all in preparation for requirements that will not be implemented for quite some time. Then my good friend YAGNI will step in – often in the form of a smiling co-worker – saying “YAGNI!”. And sometimes, I am the one to say “YAGNI!” to help rein things in. Because, you see, the iceberg often doesn’t reach us. Requirements often get de-prioritized, or other solutions present themselves as the design grows iteratively over a period of several sprints. If any of these possibilities comes true, then all that extra effort would have been wasted. Worse than that, it would have been like the gift that keeps giving. We would need to continue to maintain that extra code and complexity, adding cost to every subsequent maintenance cycle. It is the intervention of YAGNI that saves us from that fate.

Which is not to say we keep our focus locked on our feet. We remain aware of what is coming and if that iceberg starts getting too close, we make the adjustments to ensure we don’t hit it. If we end up needing the extra complexity of a more elaborate design, so be it. But by waiting until the near-term requirements demand it, we defer that extra cost until that time and we also ensure that it truly is needed.
In addition to potentially avoiding wasted effort, YAGNI also allows us to get started faster. It allows us to build in smaller, more manageable chunks. It allows development to start sooner by avoiding large, up-front design phases. It allows us to deliver more value to the business, in both the short term and long term. And that value comes more frequently and continuously.

The Product Owner follows a similar approach. Since product releases are coming more frequently, he doesn’t feel the need to “get it all in now”. He prioritizes requirements based on their true need, not based on a false sense of “now or never” urgency. He knows that if a requirement is truly needed, it can be added in the next sprint. Due to the short time frames of the sprints, the next enhancement is just around the corner. This is in stark contrast to the multi-month RUP releases or worse – the Waterfall releases that could stretch more than a year.

My good friend YAGNI has saved the day to prevent wasted effort many times. Maybe he can help you too.

Doug Hieber, Senior Software Architect
January 28, 2016

“You Ain’t Gonna Need It” and is an old extreme programming (XP) term. If you’ve never heard of it before, the author of this blog post explains what it is and how this philosophy keeps Agile developers from over-engineering.


agile post itsMy good friend YAGNI is not a person but a philosophy that we are using as part of our Scrum/Agile development process. It stands for “You Ain’t Gonna Need It” and is an old Extreme Programming term to keep developers from over-engineering the system. Over-engineering results in unnecessary complexity and cost. It delays releases and thereby delays adding value to the business. I’ve even seen it cause projects to fail. YAGNI to the rescue!

In an Agile process, we try to avoid looking too far ahead to prevent building components and frameworks in support of future requirements that may never come. Instead, we build the components and frameworks needed to support the requirements that are approved for the current sprint.

As someone who was raised on the Waterfall and RUP processes, I am frequently tempted to build for the “icebergs” looming on the horizon. This would involve increases in the architectural framework, more elaborate designs and accepting more complexity; all in preparation for requirements that will not be implemented for quite some time. Then my good friend YAGNI will step in – often in the form of a smiling co-worker – saying “YAGNI!”. And sometimes, I am the one to say “YAGNI!” to help rein things in. Because, you see, the iceberg often doesn’t reach us. Requirements often get de-prioritized, or other solutions present themselves as the design grows iteratively over a period of several sprints. If any of these possibilities comes true, then all that extra effort would have been wasted. Worse than that, it would have been like the gift that keeps giving. We would need to continue to maintain that extra code and complexity, adding cost to every subsequent maintenance cycle. It is the intervention of YAGNI that saves us from that fate.

Which is not to say we keep our focus locked on our feet. We remain aware of what is coming and if that iceberg starts getting too close, we make the adjustments to ensure we don’t hit it. If we end up needing the extra complexity of a more elaborate design, so be it. But by waiting until the near-term requirements demand it, we defer that extra cost until that time and we also ensure that it truly is needed.
In addition to potentially avoiding wasted effort, YAGNI also allows us to get started faster. It allows us to build in smaller, more manageable chunks. It allows development to start sooner by avoiding large, up-front design phases. It allows us to deliver more value to the business, in both the short term and long term. And that value comes more frequently and continuously.

The Product Owner follows a similar approach. Since product releases are coming more frequently, he doesn’t feel the need to “get it all in now”. He prioritizes requirements based on their true need, not based on a false sense of “now or never” urgency. He knows that if a requirement is truly needed, it can be added in the next sprint. Due to the short time frames of the sprints, the next enhancement is just around the corner. This is in stark contrast to the multi-month RUP releases or worse – the Waterfall releases that could stretch more than a year.

My good friend YAGNI has saved the day to prevent wasted effort many times. Maybe he can help you too.