A few months ago, I came across the term Technical Debt to describe a situation that I’ve long been familiar with: you have some code to write and you can either do it the messy but fast way, or the neat but laboured way. One usually means just hacking in a quick solution, and the other usually means careful refactoring to set-up the abstractions you’re writing to their fullest. If you decide to do it the fast way then it’s likely, even if it’s not obvious today, that you will have to maintain it a later date (no code is an island, the real cost is in maintenance etc). Thus you have a technical debt that you will have to repay at some point; whether in the form of rewriting the code to the proper way, or hacking further around it. You pay back technical debt by paying time on the principal (fixing the original issue) and paying time on the interest (having to work around something that isn’t as neat as it could be).
You can take this metaphor quite far (continued hacking eventually causes bankruptcy, for example) but I’ll leave it at that for the moment.
In the past, I’ve worked on projects where technical debt was carefully managed. On those projects, code was easy to write and maintain, and performance tended to be very high; largely because everyone understood the entirety of the code base and always knew how their decisions affected the system as a whole. This was pleasant, but required stringent regulation.
I’ve also worked on a project where massive technical debt was accrued and project management insisted on every fix being the fastest one possible, regardless of the long term consequences (I hasten to add I was largely opposed to this, but at some point you just have to get on with things). By the end, doing anything took far longer than it should have and performance began to tank. Working around the debt and managing time began to be the only thing possible, and paying off the principal never happened because there wasn’t any time left. That’s a bad situation to be in.
All of that said, if you know what you are building is a one-off or infrequently used piece of code that is needed sooner rather than later, taking on some technical debt can be the most frugal thing you can do. Rather than work on figuring out the neatest abstraction, or the nicest algorithms, just get the code working quickly and move on.
Now, I’m not saying that this is how you justify doing things the wrong way. There are rules you must adhere to in order to manage your debt.
- Only take on technical debt on one-off or seldomly accessed code.
- As soon as indebted code becomes used or maintained more frequently, and it inevitably will, you must endeavour to pay off the debt as soon as possible; before moving onto new code.
- If you’re not sure whether or not you can take on debt in a given situation, you can’t. Write it properly and forget about it.
- Never, ever, sacrifice documentation. If anyone is to have any hope of understanding your code (even the really good stuff), they’re going to need documentation. You cannot put your documentation into debt and hope someone else can pick it up easily.
Remember: all debt needs to get paid, or the whole thing can come crashing down.