This particular rant was caused by a post that doesn’t really go in the direction I’m about to, but is interesting read nevertheless (check out the comments!): Agile and Test-Driven: A Marriage Made In Hell?

I want to touch a topic concerning single acronym in this post: YAGNI, or You Ain’t Gonna Need It.

In general, I agree that YAGNI is a solid concept. Don’t build too much, especially if you’re going to throw it away later. Makes sense. Less work is better. Less code means less bugs and less time spent for no benefit. Leaves you more time to work on things that a customer wants now. Goodness, right?

Not always. If some of us are crazy for building code even though a customer did not request it (so we’re doing exactly the opposite of what’s recommended) there is a method in our madness. Why exactly are developers building more than necessary?

Sometimes it’s because customer’s behavior is actually not so unpredictable. Customers are not technical people (most of the time). They can’t think in abstract terms. So what they tell you and what they really mean are most often a variations of one and the same thing – a “hardcoded” version they give you, and a more flexible, a bit more generalized version they are vaguely aware of, but can’t express in abstract terms so you can translate it literally to code.

So you detect this situation. You don’t say anything, but you code more generalized version of what customer wants. A few weeks/months later, the customer realizes that his initial idea was too narrow in scope and wants something better/more complicated/more general.

Now, if you followed YAGNI, the chances are that the architecture of the app as is at that moment simply does not support that scenario. If you want to incorporate changes the customer is insisting on, you’d need to refactor large portions of your code. All your unit tests go down the drain, as you’re not testing the same thing any more. You end up writing lots of code with a risk of breaking big chunks of previously written code, plus you have to write a ton of unit tests again.

Contrast this to the “developer premonition” approach above. You have already incorporated the general idea, your tests reflect that so all you need to do now is to expose a GUI item or two and call the right method. You’re done. Besides from not jeopardizing the existing code, you look cool in the eyes of customer because you adapt to change so fast.

This is oversimplification of course, but once you observe the above scenario in the wild, if repeated enough, you’ll start adapting to it and ignore YAGNI. The real issue here, just like with YAGNI, is to know when to stop.

I think it’s precisely because of this – developer’s inability to stop themselves from generalizing too much – that YAGNI was introduced. When in doubt, YAGNI.

But it’s hard to fight the real-world experience. Use your own judgment and most of all, adapt to the customer.