Software Engineers talk about Tech Debt all the time, but other than it being a bad thing, they don’t often stop to explain why it’s bad, or why they are going to spend so much time fixing it rather than doing something valuable.
Martin Fowler has some excellent resources that explain this in the words of software systems, choosing to prefer ‘cruft‘ more so than debt. It’s a really strong approach. Debt means different things to different people. In business, debt can be a good thing! It lets you do more now. You claim some of the market, or you grow, and you pay back the debt from excess profits you’ve made. Overall it costs less to take the debt.
Sometimes we squint a bit in software world, take some shortcuts and call it that good kind of debt. Then we take a few more ‘quick wins’, then a few more, until we end up throwing our hands in the air and the Engineers are calling for a re-write.
Instead of that, when we think on ‘cruft’, we can take a more healthy approach. We build the smallest thing we can to service the needs of today. We build it well, and we can change it quickly. Cruft builds up as we learn more, honing what we have to the real needs of the world. Assumptions we made in the past turn out not to be valid, and we need to correct.
By cleaning up as we go we keep on top of things, keep moving fast and keep driving value at pace. If we understand this as cruft not debt, then it’s in the interest of every stakeholder to stay on top of it as we keep going fast by fixing as we go.
Bringing this back to a real world example, I’m busy looking at the windows in my house. Lovely wooden frames, original with real craft put into their creation. However, they’ve not been well maintained. Rather than a quick sand and paint every few years they have been left in the weather for years on end. Patched and painted without repair, then patched on top again.
They look OK from a distance. You could patch and paint again but it’d only cover a couple of years until you need to go again. That’s paying 5x the usual maintenance cost.
You could strip them back fully, repair everything and get into the standard maintenance cycle. That’ll cost most of what a new set will set you back, and they’ll still have some of the neglect baked in.
So you have to take them out, take out some of the supporting sills and lintels that have also been neglected and start again, a big expense but necessary to get a high quality outcome.
Back to software, and you see the same cycle. Build your maintenance in to your plans, fix as you go and don’t let the jobs get away from you. If you have to get something live quickly, then recognise that and double down on improving that area in the near future. Fix a quick fix properly, or it becomes a load bearing layer of your solution.
Don’t accept bad debt and you’ll drive more value faster for longer!
James Osborn 