YAGNI – A quick introduction and field report

About two months after I joined codecentric, I had a really interesting conversation with a colleague. I think it went like this:

Colleague: Hey, have you ever heard of YAGNI?
Me: Bless you!
Colleague: What?
Me: Did you just sneeze?
…

I am pretty sure that the conversation was like that. But seriously, he told me that in order to develop software effectively, it’s critical to understand and apply YAGNI, which is short for: “You Aren’t Gonna Need It”. I should try it and use it inside my current and upcoming projects, he said. But what on earth is YAGNI and why should it help me in software development? In this article, I would like to give you a quick overview and share some experiences.

You aren’t gonna need it!

My colleague gave me a website link [http://c2.com/xp/YouArentGonnaNeedIt.html ] to read more about YAGNI. So, YAGNI is an extreme programming technique. And one of the first quotes on the website tells you everything you need to know:

“Always implement things when you actually need them, never when you just foresee that you need them.”

Wait, what? That is simple and genius at the same time. When I read that sentence it gave me a mind-blowing feeling and I was instantly infected with the YAGNI virus.

Often, in the past, before I knew that approach, I thought something like: “What could happen with my software in the future? Oh yeah, maybe this and that. Let’s implement all these things since we are working on this part anyway. That way it’s future-proof” And what happened afterwards? Right, the implemented features, based on assumptions, didn’t work as expected by the customer or user. So in the end we had to reimplement some parts of the software to fix that. And sometimes it happens that a piece of the software is not needed or used in the future, because of reasons.

This is where YAGNI can help. By not implementing things until you need them, you can save time and prevent useless work implementing and maintaining this code.

This same principal applies on both a business level, such as product features, and on an implementation level, like software abstractions. Do you just write a class, or do you already create an abstract class with one child class because you suspect more children will come in the future?

Would YAGNI fit into your daily project life?

Short answer: absolutely. In a recent project, the above mentioned colleague and I were in the lucky situation to join the same team. And he also introduced the YAGNI principle to the rest of the team at the very beginning. It was interesting to observe how this technique was a kind of a challenge. Very often we heard someone say: “Wait, do we really need that now?”. That was amazing. They were all infected with that virus, too. One of our new team members also created a Post-It shrine at the office wall.

A big advantage of YAGNI is that you avoid unnecessary development. If you think about it, you certainly often develop software on the basis of assumptions. Also, sometimes when you think about future features, there could be obscurities. I have heard customers say “Yeah, we need feature X now”, and when you ask what the requirements for this feature are, you sometimes get an answer like “Oh, that is not 100% clear at the moment”. This should alert you. Those things are exactly what YAGNI stands for. Postpone them to a later state of the project when requirements are more clear and a feature can be developed more accurately.

But … there is always a “but” … sometimes it is not that easy. It is hard work to spread a YAGNI mindset in a team and propagate it to a customer. Over and over, you should try to challenge your opposite. Ask yourself, your team, and your client: “Do we really need this (now)?”. Whenever your counterpart struggles or doesn’t have a clear standing why something is needed, it’s clearly time for YAGNI. Then you should also think about discarding it or put it on hold until it becomes relevant again. This doesn’t mean that things aren’t important, but they are maybe still unclear at an early point in time. When they become more important at a later point, the maturity of this issue might also have grown. It might become more relevant for the client and there could be enough details for an implementation.

What YAGNI does not mean is that a feature will never be implemented only because it is not necessary at present. It should just help you to prioritise your work and prevent you from doing work that is based on assumptions. You’ll only risk having to re-do it later because the information you had earlier was wrong or not sufficient.

When using YAGNI, you might get the impression that it will prevent you from doing experiments. This would be right if you ignored the YAGNI methodology while doing prototyping. It’s best to use the technique for focusing while you create a prototype. In that case it is totally OK to do the work twice. You can then learn from the feedback. After all, your prototype might not always be what the user or client expects, so you will need to discard your idea and re-do it. This is totally fine, and while implementing trials, you also should adopt YAGNI in order not to overload your outcome. Anyway, prototyping is about trying something while being aware that it may be dismissed in the end.

Conclusion

For me, YAGNI is an excellent way to improve your software development cycle. It helps you a lot to focus on necessary features and software pieces. You should use it for experiments (prototyping) and be aware that software pieces might have to be implemented multiple times. YAGNI and prototyping fit together perfectly. Now, go find something and simplify it down to essentials right now!