YAGNI is no excuse to be lazy

There’s one thing that really really bugs me about Agile development … well, ok, there are several things, but today I’m focusing on just one … and that’s the thinking around YAGNI. In case you’re not familiar with the acronym, it stands for You Ain’t Gonna Need It.

The premise is that, in most cases, generic designs and over engineered solutions aren’t required and are overkill. Worse, most of the time the added flexibility or power is overkill, with the result the project incurred the cost of writing and testing code that is never used.

YAGNI is a shorthand reminder to developers to leave the complex solution unwritten until you actually know that you need it.

In other words, you should implement the simplest thing that could possibly work for your current situation, and let tomorrow worry about it’s own problems - don’t spend valuable time today solving problems that tomorrow may never face.

The problem is that many developers use YAGNI as an excuse to be lazy.

You see, YAGNI is a guideline that reminds you not to write code that isn’t needed. It says nothing about how you write code that is going to be needed.

An Example

Assume that you’re working on Project Wilbur, a new application for the Human Resources department at the law firm of Slapham and Sueham. Management of salaries and benefits at S&S is a complex job, with a large number of special rules and exceptions.

For example, while most staff members are paid in US dollars, there are some paid in British pounds, and one (the nephew of a Romanian Count) paid in Russian Rubbles. The two senior partners have company cars and car parks, other senior executives just get car parks, except for one who has a company Segway instead.

To top it all off, you know that the rules change frequently - in the last financial quarter there were twelve minor amendments, and that was pretty typical.

How do you proceed?

You could write a complete expression evaluation engine - one that handles all possible cases, including function evaluation, trend analysis and more - surely it would only take a few weeks, and you’d never need to touch it again.

But … you ain’t gonna need it.

You don’t need a complete expression evaluation engine - the rules you have discovered so far just aren’t that complex - all you need is something simple.

The lazy approach to this - the one often justified by YAGNI - is to build the simplest possible expression engine, ignoring that you already know that it will need to change. This means that when you need the extensions later, you’ll have to throw out the existing engine and start again.

Running counterpoint to YAGNI is another idea that is just as important - that once you know you need it, you build it properly.

In our example, we know that we need an expression engine, and we know that it will be extended in future. By applying good design principles we can implement only the features we need now, without closing the door on future extension. We can be confident that when new requirements arise we can handle them without a complete rewrite.

Conclusions

YAGNI is no excuse to be lazy - when you know the dimensions of likely change, you can (and should) build in support for that kind of change. You can do this without building anything you don’t already need.