My consultants and indeed my own software development teams often grapple with technical debt. often Products carry technical debt when they are difficult or risky to change. Technical debt isn’t listed on your balance sheet, yet it can destroy your business. It’s important to understand where Tech Debt comes from in order to effectively address it:
- A common reason for bringing technical debt into a code base comes from the business stakeholders. Assuming they have a reasonable understanding of the consequences, the business might consider getting something released sooner is of more value than avoiding technical debt. They should understand the “interest” payment that will be incurred if they insist on this path! In many cases, businesses stakeholders simply don’t understand the ramifications of what they are asking for, nor do they fully grasp the concept of. They make decisions solely on immediate business pressures rather than taking a more long-term view.
- Technical debt also comes in the form of poorly constructed, inflexible software. This may come about when functions or interfaces are hard-coded, and as such, are difficult to change.
- Lack of documentation is another reason for technical debt, both in the code itself and in the external documentation. When documentation is poor, new team members who want to modify the code in the future have a hard time coming up to speed on the code which that slows development.
Enlightened management can have a real impact on mitigating the addition of technical debt and in paying it down as you go, by constant refactoring. There is an interesting webinar on this topic available here.