Martin Fowler, author and consultant at Thoughtworks, describes yagni practice, why its is important and the costs of building presumptive features, in his recent blog. Yagni is an acronym that stands for "You Aren't Gonna Need It". It is an Extreme Programming (XP) practice which states a programmer should not add functionality until deemed necessary.
XP co-founder Ron Jeffries says that:
Always implement things when you actually need them, never when you just foresee that you need them.
As per Cunningham & Cunningham wiki:
Even if you are totally sure that you will need a feature later on, don't implement it now. Usually, it will turn out either you don't need it after all, or what you actually need is quite different from what you foresaw needing earlier. There are two main reasons to practice yagni:
- You save time, because you avoid writing code that you turn out not to need.
- Your code is better, because you avoid polluting it with 'guesses' that turn out to be more or less wrong but stick around anyway.
Martin says that when we think of a presumptive feature, it's likely that we will be wrong. In this case, an obvious cost of the presumptive feature is the cost of build i.e. all the effort spent on analyzing, programming, and testing this now useless feature. He says that if we were correct in understanding our needs. Even in this happy case, building the presumptive feature incurs two serious costs. The first cost is the cost of delayed value and second is cost of carry. He explains these costs as:
Cost of delay: Teams can build some other feature which can generate revenue.
Cost of carry: The code for the presumptive feature adds some complexity to the software, this complexity makes it harder to modify and debug that software, thus increasing the cost of other features. This impacts the additional cost to build the feature, plus the additional cost of delay since it look longer to put it into production.
Martin mentions that there is an additional cost of repair in case of right feature built wrong.
Development teams are always learning, both about their users and about their code base. They learn about the tools they're using and these tools go through regular upgrades. They also learn about how their code works together. All this means that you often realize that a feature coded six months ago wasn't done the way you now realize it should be done. In that case you have accumulated technical debt and have to consider the cost of repair for that feature or the on-going costs of working around its difficulties.
Martin says that yagni applies to large features as well as with small things. A lot of small yagni decisions add up to significant reductions in complexity to a code base, while speeding up delivery of features that are needed more urgently.