I have a mortgage on my house, and once interest is compounded over the coming years I will have ended up paying over twice my house’s value back to the bank. This used to keep me up at night.  However, I have come to see the debt as a good thing.  Without it, I would not have a roof over my family’s head, nor would I enjoy the level of lifestyle that my location affords me.

Just like a mortgage, today’s successful software projects must continuously find a balance between short and long-term benefits. These shortcuts are a strategic decision - deferring (and perhaps compounding) development costs later, in order to meet a short-term target. In software development, we refer to this as “technical debt”.

 For many organisations, resources are scarce, and the business needs to make calculated decisions on how to best use them to further organisational goals. This can sometimes result in technical debt. And while technical debt may be a common term in software development teams, the rest of the business may not be as familiar with the concept. This is important as it is often business decisions that create technical debt in the first place. And, if managed poorly, technical debt can have dire consequences, costing the business more in the long term.

 It is important to remind the business that technical debt isn’t necessarily an evil thing. Just like a loan, it can be used to your advantage e.g. to quickly develop and test a new function on your beta testers. But, also like a loan, it can spiral to unmanageable proportions if you don’t stay on top of it. I have seen systems where developers shaved a day off their development time, only to pay for it in months of development later. There is a human cost to technical debt too. The difficulty and complexity created can increase pressure on development teams due to slower than expected progress. Developing on systems with these constraints can make work less enjoyable and create challenges with recruiting and keeping quality staff.

Although it may be tempting, don’t be drawn into hiding technical debt from the wider business, thinking that it could be seen as a failure. By socialising the concept of technical debt with the wider business, software development managers can help to ensure that the necessary resources are allocated to reduce its impact.

 Technical debt creates a risk for the business, so it makes sense to manage that risk alongside other business risks. When managing technical debt as a risk, it is important to remember that this is a catch-all term that can describe both planned/identified technical debt as part of a decision-making process and the unplanned effect of developing software without a clear roadmap and solid architecture. In other words, all technical debt can’t be treated the same or as one thing that needs to be fixed.

 Businesses prefer making informed decisions on creating technical debt. To support this, good software development managers go beyond communicating the impact of taking on technical debt. Instead, they take the time to ensure that the business understands what technical debt is, including all the benefits and consequences, and how it can be managed best. This way, businesses can develop a strategy to reduce the risk technical debt can present.