Category software development

Earlier this year, I was discussing features for a project with the team. I casually mentioned YAGNI in response to one aspect of a feature that seemed unnecessary. It had been a while since I’d brought up this term and a couple newer developers on the team were puzzled. I paused and realized this wasn’t something they were familiar with. So we discussed what YAGNI was. They were familiar with the concept but not the term. I asked some others on the team afterward just to see who was familiar with it and it turns out that many in the current generation of programmers aren’t. I would be curious to know how many readers of this post know the term or need to stop to google it.

YAGNI is an acronym for the phrase “You aren’t gonna need it” and is a principle from Extreme Programming (XP) that’s closely aligned with another principle “doing the simplest thing that could possibly work”. It’s used as a practical way to combat future proofing or overengineering a feature’s implementation. You can read a lot more about it on this page from Ward Cunningham’s wiki. BTW, that is the first wiki by the person who invented the wiki. Cool, huh?

Ron Jeffries, another XP founder, has a succinct way of describing YAGNI:

Always implement things when you actually need them, never when you just foresee that you need them.

The cost of change in software is high enough to justify avoiding building things you don’t need. I’ve certainly gone back and forth on this over the last 20 years thinking that in some cases, I really will need it. In almost all cases, I either didn’t need it or I needed it in a different way than I imagined. In hindsight, it was clear that I would have benefitted from holding off entirely on the implementation. It’s important to realize that this kind of code is a liability and a burden on future maintenance and enhancements. Thus building anything you don’t need is a detriment, not to mention wasting time and money.

Another wonderful read on YAGNI comes from Martin Fowler on his bliki. He digs into a concrete example of YAGNI at play and does a fantastic job at explaining the costs of not invoking YAGNI. As a side note, if you aren’t familiar with Martin Fowler’s writing, you should look it over when you have a spare evening or two. Martin has such concise thoughts on how programmers go about their jobs and I’ve had mindblowing moments reading his work.

YAGNI plays a greater role in our team’s world since we do a lot of prototyping on new products. You can imagine how often the opportunity comes up to defer some part of a feature on these projects. Knowing when to invoke YAGNI and when not, is something that takes experience to get the nuance down. If you’re not sure, then don’t build it. Let the pressure to add that part of the implementation build until it’s clear it’s needed.

In thinking about how YAGNI is no longer well known, I wonder what else the new generation of programmers isn’t aware of. It’s worth mentioning that I didn’t discover YAGNI or the other XP concepts until 7 years into my programming career. Did I know what I was missing? No. But my ability to build high quality software efficiently was noticeably improved by incorporating these concepts into my daily work. One important part of our mentorship approach is to bring these ways of thinking into the next generation of programmers.

What other principles like YAGNI seem to have faded from the consciousness of programmers?