Yagni originally is an acronym that stands for “You Aren’t Gonna Need It”. It emerged as one of the key principles of Extreme Programming. Put another way, the principle states:
“Always implement things when you actually need them, never when you just foresee that you may need them.”
There are a number of reasons why this principle exists. Firstly, it maximizes the amount of unnecessary work that is left undone, which is a great way to improve developer productivity and product simplicity. Features are expensive, both to develop and maintain, and for users to learn & navigate around. Features that aren’t actually necessary are a huge source of waste. Our software needs in the future should not be built now because “you aren’t gonna need it”.
You can think of YAGNI as being similar to Just-In-Time (JIT) manufacturing. Rather than ordering a bunch of parts based on what you think you might need, wait for actual customer orders and ensure your process is lean enough that you can pull orders through you supply chain quickly enough to satisfy your customers. Now, just as JIT only works well in manufacturing organizations that are disciplined enough to follow lean principles, the case can be made that YAGNI works best in environments that ensure their code is kept in a malleable, changeable state.
Scrum philosophy of working in small teams, small sprints, small stories imbibe simplicity thinking – Thoughtful reduction.
Simplicity leads to:
- Decluttering of products.
- Decluttering of your mind. Not being manipulative – being honest, open and trustworthy.
- Decluttering your workspace, working in open spaces.
The common reason why people build presumptive features is because they think it will be cheaper to build it now rather than build it later. But that cost comparison has to be made at least against the cost of delay, preferably factoring in the probability that you’re building an unnecessary feature, for which your odds are at least ⅔.
“The cheapest, fastest, and most reliable components of a computer system are those that aren’t there.” – Gordon Bell
It’s easy to continue developing a product beyond some point. A Standish Group survey in 2009 stated that over 70% of functionality is never or rarely used. Not doing that work is a great opportunity to do more valuable work.
Few Agile thinking and practices that come to my mind are:
Thoughtful reduction of hierarchy within the organization is a step towards simplicity.
Having only 3 roles in Scrum (Team, ScrumMaster and Product Owner) on a team is simplicity.
Using simple task boards to measure progress.
Product Owner decluttering backlog to identify features that will make his product successful.
Building working software just enough to get feedback.
Writing just enough documentation to serve a need.
Use of story cards (As a customer, I want to do something, so that I can get some value). You don’t do anything unless the value can be clearly stated.
Yagni is at its most visible with larger features, but you see it more frequently with small things. Yagni only applies to capabilities built into the software to support a presumptive feature, it does not apply to effort to make the software easier to modify. Yagni is only a viable strategy if the code is easy to change, so expending effort on refactoring isn’t a violation of yagni because refactoring makes the code more malleable.
