Why is YAGNI a good rule?

24 August 2013

YAGNI, short for You Ain’t Gonna Need It, is a common rule of thumb in software development. YAGNI is the idea that developers shouldn’t introduce code into a program until that code is actually needed. This may sound like an obvious idea, but in practice it’s suprisingly tempting to add code that, while not strictly necessary now, may make your life easier in the future.

I’ll give an example: suppose you’re working on a piece of code that adds pets to Minecraft. The pets will follow the player around and maybe fight off creepers or zombies. Ultimately, you’re going to add dogs, cats and chickens to the game, but for now you’re just working on dogs.

So you get started adding some code to govern the dogs’ movements and AI. As you go, you think to yourself, “You know, a lot of this code will prove useful when I implement cats and chickens; I’ll introduce a Pet class that defines all the common behavior that my Dog, Cat and Chicken classes can inherit from.” So you create a Pet class and split your implementation of dogs between the Pet and Dog classes, depending on what you think is generic code and what you think is dog-specific.

This is a YAGNI violation and a bad development practice; you’re introducing a hierarchical class relationship where one isn’t needed. At first, though, it isn’t obvious why this is bad. After all, it really might be the case that when you have dogs, cats and chickens all implemented, you’ll want to reduce duplication by moving common functions into a Pet class. So what’s the problem with getting started early?

The problem is that determining which parts of the dog’s behavior belongs in the Dog class and which parts belong in the Pet class is really difficult. In order to figure this out, you need to imagine not just how you want the dogs to behave, but also how you want the cats and chickens to behave in the future. You have to hold everything your head – not just the current design, but also the future design that you’re putting the Pet class in place to support.

If you really think you can do that well, go ahead. Personally, I find that software is hard enough to effectively design in the present. When you throw vague ideas about how the program might work in the future into the mix, you almost always end up with the worst of both worlds: a program with a design that’s bad today and not really that useful tomorrow.

And really, that’s the problem with all YAGNI violations, not just those that introduce an unnecessary class hierarchy or an abstration that only ‘abstracts’ away a single operation: they always stem from a form of arrogance about program design on the part of the developer. When you put YAGNI code in place, you’re saying that you’re not only able to solve the current design challenge – you’re also going to solve next week’s problem as well. In reality, you don’t really know how to solve next week’s problems until you sit down and actually start focusing on them.

Edit: A bunch of people have been discussing this article on Hacker News.

comments powered by Disqus