Number 15
August 9, 2023

Procrastinate your way to better code

I once told you that there are three bits of advice programmers always receive: KISS (“Keep It Simple, Stupid”), YAGNI (“You Ain’t Gonna Need It”), and DRY (“Don’t Repeat Yourself”). Some people think of these not as mere advice but as principles. I don’t go as far as that; as I said a few weeks ago, I don’t agree with DRY and think that it goes too often in total opposition to the other two.

A cart full of horse muck.The more that piles up, the more it stinks.

Today, I want to sing you the praises of YAGNI, which means “You Ain’t Gonna Need It.” It comes from the observation that we sometimes start writing code that we think will fulfill our future needs, but in the end, we rarely end up using it. Therefore, we should wait to write it until we need it.

Think of all these times when you added an abstract interface so you could replace the database if you needed to (you never did) or when you wrote that extensible framework of which you only ever used three functions. We could waste lots and lots of time doing things now that we won’t use in the future, and the YAGNI acronym reminds us to avoid making that mistake.

That’s not the only way we can waste time writing code “for the future.” Sometimes, miraculously, the day arrives when we can use that code we wrote three months ago. We start integrating it, and some hours or days later, we discover it doesn’t work for us! I once joined a project in which an engineer had invested a couple of months implementing CBOR to store data compactly. When we started work on the storage system, it turned out that the native representation was already compact enough, and we didn’t need CBOR at all! Two months of work went straight to the trash.

Another reason why YAGNI is good advice is that it’s always better to have less code. The more code you have, the more places that exist where a bug can hide, and the program becomes more complicated, hard to understand, and hard to maintain. That is especially true for unused code since it is all cost with no benefit. Once, while doing some maintenance in a program, I discovered a field that was never populated. I removed it, and then I got rid of all code that referenced it, and then I realized this enabled me to do a refactor to simplify the rest of the program, which let me delete eight thousand lines.

The day I remove eight thousand lines is always a good day.

Every time I forget about YAGNI and write code “just in case,” I regret it, so I always try to follow it when I program. It’s straightforward: whenever I’m about to write code, I ask myself if I need it, and if the answer is no, I don’t write it. Today I write today’s code; tomorrow, I’ll write tomorrow’s code.

That doesn’t mean I’m looking only one step ahead without thinking about the future. I always have plans and general ideas for what I’ll do later, and I try to write my code so that it’s easy to execute these plans, but I don’t write “generalizable code” or anything like that. It’s a common temptation (and I have fallen into it a lot,) but it brings you nothing but delays: it takes longer to finish today’s work, makes it harder and slower to work with my source code, and I often have to undo it.

The illustration for this Coding Sheet is based on an engraving by Thomas Rowlandson.