YAGNI - a perfect filter for time-effective programming
YAGNI is an acronym for ‘You Aren’t Gonna Need It’ and stem from eXtreme Programming (XP) used in agile software development teams mainly. Long story short, YAGNI says that only up-to-date stuff should be done. This basically means that even if something might be needed in the future, it shouldn’t be done NOW.
The YAGNI principle states that you should be concentrating on your current tasks. However, it doesn’t mean that you’re banned for thinking a few steps ahead. You should – YAGNI doesn’t exclude principles like SOLID and others enabling project extending. So, this principle doesn’t force building inflexible solutions. It says only about not introducing over-engineering into the current work because some solutions MIGHT be useful later.
eXtreme Programming in agile software development
The XP is a framework contained in agile methodology created by Kent Beck, Ron Jeffries, and Ward Cunningham. XP refers to iterating the flow of work – teams work in short timeframes called iterations (1 – 4 weeks). Developers work in small teams, delivering previously planned functionality. Of course, there are much more rules providing high quality, e.g., pair programming, frequent releases, multiple coding standards, and more. Extreme programming promotes simplicity, emphasizing the KISS principles described below.
YAGNI in agile/XP
One might say that this principle is stupid and the requirements should be prepared better, but people working in the agile methodology should be aware of possible changes in client requirements. That’s why future tasks often depend on the results of the current project status and might be altered. If you do a lot of features that ‘might be needed’ in advance, you waste not only the time and effort that was necessary to complete those. You also burn the time you spend on fixing or refactoring them after they turn out to be redundant. Developers shouldn’t rely on presumptions because those are likely to prove to be not worthy of the time and effort of a programmer.
YAGNI vs. KISS
KISS is another design principle widely used in programming. This acronym stands for ‘Keep It Simple, Stupid’. It’s a principle with a beard, actually about 60 years old, and works for many branches of engineering – this alone tells us how essential this rule is.
More to the point, KISS says that things should be created in the simplest way possible. It allows team members to proceed with extensions, fixing, refactoring, and understanding designed features easily. The difference lies in the scope. KISS asks for the whole solution but coded as simple as possible. On the other hand, YAGNI doesn’t require a complete solution because programmers don’t know if the requirements stay unchanged and whether they will be needed in further project development or not. However, regardless of choice made, both rules require the lowest complexity possible.
Over-engineering
Writing the article about YAGNI, there is no way to omit this topic. Over-engineering is a situation where a client orders a kayak and gets a yacht. Both can float, but the yacht is like a luxury house on the water with many facilities. Max Kanat-Alexander (author of the “Code Simplicity: The Fundamentals of Software”) wrote: ‘When your design or code actually makes things more complex instead of simplifying things, you’re over-engineering.’
The reasons why developers do more than they should are different and depend on project situations. Deadlines, pressure, poor experience, permanent conceptual changes, to mention only a few of them. Unfortunately, having more than we need causes problems as well, like more bugs, increased code complexity, higher entry threshold, more resources are needed, delays occur, and so on.
That’s why managers, leaders, and more experienced team members should monitor the process of code development to make sure that everything goes according to the plan and specifically required things are done. It’s very hard to detect over-engineering in practice because it doesn’t occur directly and immediately.
What about the advantages of YAGNI?
The main reasons to use YAGNI are:
- saving time equals saving money (it’s the most important factor),
- having better, easier, and ‘guessless’ code.
Even though there are, in fact, only those two, they ensure:
- that deadlines are available,
- client’s happiness because of visible and frequent changes consistent with the specification,
- better code quality dictated by the fact that developers focus on a smaller task (the ones that are really essential at the moment),
- that code is more extendable,
- a reduced number of required refactoring,
- that bugs are easier to fix.
These reasons are sufficient to see that our work and products are better and more professional while using good practices like YAGNI, KISS, and SOLID. Every developer should know them and remember those principles, as they made our daily work easier and more valuable. Remember that in many cases, less means more. Don’t make tasks more complex than they are. Engineers make life easier by creating software, so why don’t they make it easier for themselves as well?
Last but not least, the YAGNI rule isn’t so easy. Developers have to decide on their own if something is needed or not at particular project stages. Martin Fowler, in his article, wrote: ‘If you do something for a future need that doesn’t actually increase the complexity of the software, then there’s no reason to invoke YAGNI.’ Fowler also mentioned YAGNI-related mistakes and their costs, saying that these costs are limited when YAGNI is used successfully. That’s why you need to have some experience to use YAGNI properly – you have to think about it, but don’t go crazy about it.
Just follow YAGNI and Leonardo.
“Simplicity is the ultimate sophistication.”
~Leonardo da Vinci
