For those of you unfamiliar with the term, technical debt is a metaphor that describes the impact of poor software development. It’s an interesting concept and, in a world full of philosophies like ‘just ship it’ and ‘done is better than perfect’, it offers a grounded counterview on the dangers of rashly producing code. And just like its financial cousin, failing to manage your technical debt will eventually lead to it coming back to bite you in the ass. Hard.
Think of technical debt as a sum of consequences that accrue due to making quick and dirty decisions. The more messy your code, the more shortcuts you take, the harder it becomes to scale and build upon. Effectively, by loading up on technical debt, you’re incurring ‘interest payments’ in the form of extra effort that you have to take on with every future development.
It’s a fascinating analogy and, even without being aware of the correct term, it’s something I’ve encountered a lot throughout my career as both a developer and a manager. I’ve worked on projects that incurred a lot of technical debt in order to hit deadlines and then suffered the consequences thereafter; I’ve also worked on projects where we purposefully blew timescales to minimise debt and reduce the chances of software entropy occurring later on. It’s a tough balance.
In a perfect world with endless budgets and guaranteed business success, technical debt would never be a factor as everything would be considered and implemented perfectly from the start no matter the time and resource implications. In reality though, this just isn’t possible and the businessman in me knows that debt is a necessity of life. We certainly shouldn’t ignore the fact that, just like money, using credit to facilitate an end goal can be incredibly advantageous.
Is there a large benefit in being first to market? Then take on the debt. Do you need to trial a concept before investing too heavily? Then take on the debt. Are there certain features absolutely necessary to achieve before you run out of cash? Then take on the debt! Sometimes, as Seth Godin puts it, you just need to fight the lizard brain.
“Ship often. Ship lousy stuff, but ship. Ship constantly.”
Whilst I agree that we’re becoming too focused on producing baseline ‘viable’ products instead of genuinely ‘loveable’ products, you can’t create applications in a vacuum with no consideration of the outside world. Indeed, the key seems to be in knowing about technical debt and making the decision to take it on consciously, not just living on credit blindly. Just so long as you know that one day you may need to come back and refactor the shit out of your work – and have considered those implications – then that’s OK.
Ultimately, like most things business, it boils down to making a judgement call between two consequences. Unfortunately, this weighing up of options has no secret formula or algorithm and relies on experience, knowledge, and instinct. But then that’s what also makes life so damn interesting.