In the agile community we use the acronym YAGNI to remind ourselves to stay away from building (however cool) stuff that no-one is asking for.
If used wisely, the YAGNI veto will help teams maintain velocity over time and let them focus on delivering true business value early and often.
Now when we start adopting Lean Startup principles, it’s time to learn a new acronym: YANIA!
YANIA means You Ain’t Needing It Anymore, and is a direct corollary of doing one or more lean startup-style pivots.
It’s obvious when you think about it.
You have a great business idea, let’s call it A1. You write and deploy some MVP to test the validity of the idea. You learn that it wasn’t that smash hit you that would make you economically independent for the rest of your life. (The first try seldom is.)
So you go back home and put on the thinking cap again, and revise your idea somewhat. Let’s call the new idea A2. You and your friend code frantically for a couple of days and deploy an MVP to some cloud platform. A2 is more or less the same code as A1, but with some added and some reworked features.
A2 wasn’t a huge success either, so you had to do some radical thinking. The result was B1, a rather different idea than A, but inspired by it. Build an MVP, learn, tweak the idea, repeat.
Repeat as many times as you can afford, and eventually your site is a huuuge success. But now the code is not only supporting the ideas A1+A2. It has pivoted so radically so many times that it is supporting A1+A2+A3+B1+B2+C1+C2+C3+C4+D1+D2+D3+D4+D5+D6. (This is because you know that rewriting code from scratch is almost never the right thing to do!)
Everything is fine, except for one thing.
The velocity has gone down. The team is not that agile anymore. Throwing in more people will only make things worse. Build times have steadily gone up from 32 seconds at the good ol’ A1 times to a whopping 18 minutes and 47 seconds when we build a code base that supports not only idea D6 but also the ideas A1+A2+A3+B1+B2+C1+C2+C3+C4+D1+D2+D3+D4+D5.
In order to speed up the Continuous Delivery pipeline we have cut some corners, and disabled some of the automatic integration tests. Or we just stopped writing automated tests, because it was faster to test manually than to wait for feedback from Jenkins.
You should realise that You Ain’t Needing It Anymore. YANIA!
Just kill the code that supports the ideas A1+A2+A3+B1+B2+C1+C2+C3+C4+D1+D2+D3+D4. Well, perhaps you should keep D4, since D5 relies on it. Actually, one of the features we developed for D2 is quite popular. But most of D2 is crap that no-one uses, I think. Oh, there is one thing in C2 that people still love. We can see that from the access logs. Ah, there is some supporting code from idea B1 that is used by D4, so that must stay.
I can’t kill any code at all, because everything is a mess! I don’t have runtime information! I really don’t know what parts of my code people actually use!
I need a tool that helps me detect Truly Dead Code, code that no real user has used in production for the last X days. No matter if the code was developed to support business idea A, B, C or D.
Can you give me that, please!