Technical debt, as defined by wikipedia:

Technical debt (also known as design debt or code debt) is a neologistic metaphor referring to the eventual consequences of poor software architecture and software development within a codebase. The debt can be thought of as work that needs to be done before a particular job can be considered complete. If the debt is not repaid, then it will keep on accumulating interest, making it hard to implement changes later on.

I think the use of the word debt here is absolutely superb! The two really are similar in almost all ways I can think of. Take for example, the concept of interest.
Getting into debt means you have to pay interest. If the debt becomes too big, the interest can become so high that all you’re doing is paying interest off and no more money goes towards capital repayments.

Similarly, allowing technical debt to grow out of control means that you will be spending more and more time on paying off your “interest” (i.e. the extra work generated by the debt) and less and less resources will be available to work on the stuff that matters.

Anyone that has worked on software with bucket loads of tech debt knows this part of the metaphor really well. What I’d like to talk about today is that the other part of the metaphor also applies: debt is not all bad!

Debt is just another way of saying credit and credit is very important. You need credit to make large purchases, like a house, or to finance a budding business. Credit only becomes a problem when it gets out of control, but well-planned, affordable credit is key to economic development.

Similarly, technical debt is not all bad and it can add value to an organisation. When it is well managed, it can help get a product to market quicker, it can help prototype and experiment with features faster, it can be immensely useful. The key phrase in there is well managed. Allowing the debt to get out of hand will probably mean that all the speed a team gained in going out to market quickly is lost when bugs need to be fixed and features need to be added.

An experienced engineer should know when the time is right to clean-up some debt and when to let it linger a bit longer. Sometimes it’s appropriate and sometimes that God object just needs to go and you can’t have it any other way. Knowing when to do either of these is the hard part; I’m still learning how to gauge that.

If you find this topic interesting, I recently found a great piece about code debt that explores it a lot more than I have done here and that I would strongly recommend you check out: Technical Debt 101