I recently overheard two software engineers discussing a feature they were developing. They had two options: developing the feature specifically for the task they had at hand, or do something more generic that could fit future possible use cases. One engineer claimed that they only need a very specific implementation at this point in time, so there was no point in going the generic path, while the other engineer acknowledged this fact but countered that the generic development will waste at most a few weeks so it wasn’t a big deal.

I think that he was very, very wrong.

There’s a term in Agile development (real Agile, the flavor from the 2001 manifesto, not the “certified SCRUM master” flavor) for this fallacy: YAGNI. You Ain’t Gonna Need It. And the case against developing a YAGNI feature is more complicated than what you might initially assume, with costs much higher than simply the time wasted on building the feature.

Development Time

The first, and most obvious, component of the cost of YAGNI is the actual time it takes the team to develop the YAGNI aspect of the feature. In the example above, let’s say 4 person-weeks. If you assume an hourly rate of $100 for a software engineer, and 40 work hours a week, we’re talking about $16,000. And this is not counting any sick or vacation day taken during the development, interrupts to the engineer’s peers or manager for review, etc. But this is only the first cost – albeit the easiest to quantify.

I believe, though, that even if it would take zero extra time to develop the YAGNI aspect of the feature, you still shouldn’t. To understand why, we need to go deeper.

The Road Not Taken

The second component of the cost of YAGNI is what you didn’t develop. What else could’ve fit in these 160 person-hours? would it cost the same to develop the same feature set in 4 weeks? maybe so, but costs might be higher due to changing circumstances. For instance, your best engineer might go on a maternity leave and pass the work to her team mate, who might be significantly slower in development – or he may accrue more technical debt than she would have. In addition, what would’ve been the business impact of the feature you didn’t develop? maybe it would’ve been the tipping point for finding your market fit. Now you’ll never know.

Long-term Costs

Now it gets trickier. Do we understand what are the long-term implication of a YAGNI feature? These might be either of several aspects; first, there’s the cost of actively maintaining extra code. That’s more code to read, more code to review, and more code to refactor. Second, a more complicated design creates code that is harder to read, harder to understand, and harder to refactor, because the extra feature might be coupling us or limiting us in a way that the simpler feature would not have. Finally there’s the cost of getting the YAGNI feature to comply with what we actually need.

Of Sunk Costs

Yes, there’s always a chance that you got it perfectly right in the first go. But if we’re being honest with ourselves, that never really happens. You eventually need to choose between making changes to your YAGNI feature to fit the actual needs, or cramming the needs into what’s already been implemented. And moreover, the mere fact of having a piece of unused functionality in your design might limit your ability to grok the emerging design for the actual requirements. The extra code might introduce unexpected behavior or bugs to existing software, and worse – since it’s never been used, problems might only arise when you started using it, making it harder to pinpoint the origin of these problems. There’s also the slim chance you’ll just decide to remove this feature altogether, but given the psychology of sunk costs, that is highly unlikely.

These Are Not The Droids You Are Looking For

To finish off, we should circle back to the beginning of this post. The best reason for not developing YAGNI features is simply that you have no clue as to what you’ll really need if and when the feature will actually be required. And given that human beings are terrible at predicting the medium-to-long-term future, there’s a much higher chance of developing the wrong thing than developing the perfect feature. Be humble, accept that you’re only good at predicting short term needs and try to train yourself to always shout “YAGNI!” when you hear someone suggesting making things “more generic for future requirement” or “to save time later on”. Spend that time on perfecting your current offering, on refactoring your code or on a fun day for your team – any of these will yield better results in the long term.