Hey Developer, YAGNI I tell you

In my previous post I mentioned that some of you are displaying signs of having issues with YAGNI. The YAGNI is some sort of mental illusion that is very common in developers, this illusion mostly affects your ability to produce quality code. And as you may have read in my previous post that is what is most important for a developer.

So what is YAGNI, well first of all it stands for “You Ain’t gonna need it” which is the name for a principle that states that; “a developer should not add functionality until it is necessary”. I like the way Ron Jeffries describes it even better; “Always implement things only when you actually need them, never when you just foresee that you need them” (both quotes are roughly taken from wikipedia).

Ok that is simple, just don’t do anything you don’t have to do. Well apparently this is harder for us creative guys than it seems, tell the same thing to someone working in a factory or anywhere else and they will look at you as if you where an idiot. Why in the world would they do something other then what they have been asked to do? For example you go and pick-up your newly ordered car and the sales person tells you, “Yeah the guys in the plant added an extra steering-wheel for you, just in case you would want go to Australia”. Not gonna happen, but we developers are different, we almost always add this extra steering-wheel to our software.

Maybe this is not entirely fair as we would not actually add a second steering-wheel to a car, but the number of times YAGNI is violated is still very high. The violations are usually very subtle and don’t seem very harmful and Hey we only do it to help out our client right? We would never spend the extra time on something if we didn’t know they would need later on.

But how do you know? How can you tell with certainty that what you just added is actually what is needed later on? You can’t! Even if there is a clear requirement, the code base might change so much over time that you will need to rewrite your solution. And if there is not even a clear requirement then why are you working on it? This is working on assumptions.

What is an assumption? I like this answer on a Yahoo forum; “An assumption is when you like to think you are right, but guess what? You are wrong! It over looks facts and goes on one’s own prejudice of facts”. Or in my own words “You Are Guessing”. Now that sounds a lot worse then saying, we added this and that because it is almost certain that we need it later on. But it is the same thing, just different wording to describe the same behavior.

So why is this bad? Well because if you spend x number of hours thinking, implementing and testing the functionality (lets assume you have actually been thinking about it and have properly tested it). And it turns out that it is not needed, or needed in a different way; then you have been stealing from the project / your boss / your client. If by any chance your guess about the functionality was correct then you have been lucky. Is that really how you want to work, do you always want to guess what you should build, I don’t because the chances that I make the right choice time over time again is very small.

And the added code will drag you down, when ever you need to make a change or extend the code this added code will be in your way. You will have to maintain it as well, some changes will be harder to implement because of it. And all this without any added value! That is right it did not add value, because it is not what was needed.

I have seen this time over time again; It is always easier to add new code then it is to change existing code! Period

So what can you do about it, how do you stop yourself from acting on these illusions? Well the first step, as with any problem, is to recognize it. Start thinking about the functionality you are creating, and always ask yourself the little question; Is this YAGNI? And be honest to yourself, if the answer contains something like this (list is not conclusive); “It might”, “Maybe”, Later we need” or “Cool” then you should wary! Then when you conclude it is indeed YAGNI then you just need to say; “Not Gonna Happen”, not yet anyway. This requires self discipline and good knowledge of the tasks you have to fulfill, but it is definitely an achievable goal and I encourage you to pursuit this goal.

If the functionality that you concluded is YAGNI is indeed very interesting then this should be discussed with the stakeholders and when they conclude it is indeed then it can be made into a scenario for you to create at a later date. The difference is now you know what is needed.

Now here are two more very interesting blog posts about similar misguided practices one by Scott Bellware and a follow up on BlogCoward. You should read both of them!