YAGNI Revisited

"You aren't gonna need it" (YAGNI) is a phrase used in software development to help combat complexity and prevent building unnecessary components. It's a great idea but one rarely implemented. What I see most often are cron schedulers with api endpoints that put data onto an AWS queue and use an RPC framework internally for no good reason. I.e., the complete opposite of following the YAGNI principle.

(fair warning, when I say "prove" below I'm not talking about a formal proof, instead research or build enough to convince yourself)

Assumption of None

I had an insight the other day that led me down an interesting path.

Once you have a problem to work on, but before making any technology choices or writing any code, assume that the problem is already solved. Assume that you, personally, need to do nothing.

No, seriously, assume that you need to do literally nothing to solve that problem. You sit on your hands and the problem is magically solved in front of your eyes. Silly right? Stick with me...

What does this actually mean? Well, if your problem hasn't been solved in the time it takes you to open a new browser tab, it means that you need to do a quick google search to figure out if someone else has written the thing you think you need. Even more so, it means thinking about your actual need (hammock driven development for the win!).

Once you've done that, prove yourself wrong. Prove to yourself that no one else has written an app or bit of code that does the thing you need.

At this point, you've proven to yourself that no one else has something that fills the need. Great! Don't start writing code yet.

Is there a group of technologies that can integrate with one another to provide the functionality? Again, assume that there is and see if you can prove yourself wrong. Nothing exists? Great! Now you can start thinking about writing code.

But, as you do, continue to make assumptions that you don't need (insert thing here) and prove yourself wrong. Assume you don't need to persist data until it becomes bleedingly obvious that you do. Assume you don't need a database to persist that data and a flat file will do, until you can prove that assumption wrong.

Proving assumptions wrong all the way up and down the stack is a great way to prevent yourself from building in something you don't need or using a technology that's too complex for your current use cast. It's a way to ruthlessly force yourself to build something that's tailored to your situation.

Other Benefits

You know the great thing about building something like that? It's extensible. You can always add more on later, after your assumptions prove false. It improves developer speed, both from a bug-squashing perspective (it should be obvious when there's a bug because your code doesn't do the specific thing you need it to) and from an onboarding perspective.

I don't necessarily mean a new developer to the company by "onboarding" by the way. I mean getting a developer that's unfamiliar with the codebase up to speed and productive in the codebase. This includes you if you haven't looked at the codebase in a couple days, by the way!

This increases developer productivity which in turn means business velocity. If you're building the thing you need and only that, you can move at lightning speed. That's the goal, isn't it? Move faster than your competition and maintain that velocity for as long as possible.

You're also building in a lack of code ownership. This, contrary to popular belief, is also a good thing. It means when your code no longer fits your need, because your needs diverged, you can toss the code out and use the lessons learned to move even faster on the new need. Even in this case, go back to the basic assumption that you don't need to build anything, and prove yourself wrong every step of the way.