Technical Debt is a Tool.
Technical Debt is probably the worst Nightmare of every Software Developer. Yet — as a Product Manager it is one of my favourite Tools to work with.
Many people in the software development community compare technical debt to a loan. You trade development speed (e.g. to ship a certain feature sooner) for a certain amount debt in your code base. This debt usually means ugly code, bad documentation and edge cases that aren’t handled properly.
Technical debt is usually regarded as a very bad thing. Some developers advocate that technical debt should be avoided as much as possible. Why? Because it lives on in your code base and gets more and more expensive over time by introducing weird behaviour into the system and increasing the complexity of the code base. Ugh, no one wants that!
While the metaphor of technical debt sometimes is useful to explain the downsides of rushing something out of the door I’d like to paint another picture here, kind of advocating for (clever use of) technical debt.
Conscious acceptance of technical debt can be worth a lot. It helps with time to market if you need to have something ready before your competition can offer it. Shipping functionality sooner rather than later also buys you information about whether the thing you are building actually makes sense. This can help to de-risk going down a certain path or even help you save resources by figuring out early that the feature you plan to ship wasn’t a great idea to begin with.
On top of that, technical debt sometimes doesn’t have to get very expensive at all. If you are smart about it you can clearly separate a part of your code base from another (separation of concerns) which allows you to put your technical debt under quarantine, so it doesn’t affect/spread into other parts.
Sometimes replacing a hacky solution with an open source lib or a third party tool is also an option. No need to clean your mess up at all, you can just throw it out.
In the end it just comes down to understanding whether technical debt is worth it and how to use it to your advantage. Every code base has technical debt. I believe it is more useful to understand how technical debt works and behaves over time instead of trying to dogmatically pretend it doesn’t or shouldn’t exist at all.
Also make sure to check out Allan Berger’s excellent post on the advantage of short user stories.
Technical debt is a tool in your toolbox. Use it to your advantage.
If you found this post helpful you might want to follow me on twitter where I tweet about Software Development & Product Management ☺
Also make sure to check out Blossom an Agile/Lean Project Management Tool I’m currently working on ☺
