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 that should be avoided as much as possible as 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.
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 de-risk going down a certain path or help you save resources by figuring out early that the feature you plan to ship wasn’t a great idea to begin with.
Also make sure to check out a similar post on the advantage of short user stories by Allan Berger.
Technical debt is a tool in your toolbox. Use it to your advantage. That said, it obviously is one of the tools that need to be handled with care and should only be used if well understood.
If you found this post helpful you might want to follow me on twitter where I tweet about Software Development & Product Management ☺