A Debt That Can Never Be Repaid

I’ve been writing code for over twenty years. In twenty years, I’ve learned there’s never enough time to write all the code I want to write.

Developers have been struggling with the constraints of time since the first lines of code were punched into cards. There is never enough time to add all the code we want to write into the program.

I’ve seen this problem tackled in many different ways. TO DO lists, TO DO comments and tech-debt tickets are just a few. The principle is always the same: take a note, leave it for later.

And, without fail, the same thing happens. The software grows, the requirements change, new requirements are introduced. The tech debt never gets addressed.

This is a problem. Tech debt can only be one of two: important or unimportant. If it’s unimportant, keeping track of it is just noise. Why do it? If it’s important, we’re knowingly leaving a problem to fester. This is even worse.

If there’s one lesson I’ve learnt from experience, it’s this: don’t take on technical debt. If this means delaying a new feature, so be it. Be transparent with your constraints. Deliver a done product, not a patched solution.

There are few things more frustrating when coding than to find a three-year-old TO DO in the code. Is it still valid? Should I investigate?

If it deserves keeping track of, it deserves getting done. As Nike said, just do it.