Technical Debt: What it is and How to Manage it

It’s rare to find an environment where there isn’t pressure to deliver early. To respond, little shortcuts are often taken. Slap in some code without comments, skip some testing scripts, or install a bit of code that doesn’t quite fit into the overall design of a solution. Is this the wrong thing to do? Maybe, maybe not. But what these shortcuts do is create technical debt, an accumulation of work that needs to be addressed downstream.

So how do you manage technical debt? Here are a few approaches:

Track shortcuts diligently and address them! Putting working code into the hands of users sooner can be a fantastic business decision, even if a technical shortcut is involved. Problems arise when that shortcut isn’t corrected, leading to errors downstream as working code becomes a vital part of business processes. Any shortcuts should be captured as a priority one requirement to be resolved as soon as possible, “paying off” technical debt.

Resist the temptation to accumulate technical debt. Taking shortcuts results in delivering quickly but usually compromises quality. Ensuring the team’s focus centers on quality and only turns to shortcuts in critical business situations will keep technical debt off the project’s balance sheet.

Schedule “technical debt recovery” time. Whether to deliver quickly or use a “quick and dirty” approach to correct code to circumvent a stubborn error, accumulating technical debt is common when building an intricate system. Project managers with foresight anticipate this and schedule time to fix issues that contribute to technical debt. On a waterfall project, add contingency time to the schedule. In an agile environment, prioritize features to address technical debt.

Assess the complexity of requirements or features. Technical debt is often created when teams take shortcuts to bring a complex function to fruition. Include a complexity factor when evaluating requirements and contrast the risk complexity surfaces with the business criticality of the function being requested. Avoid including complex features in the Minimum Viable Product (MVP). Consider the potential for accumulating technical debt when evaluating a change request in a waterfall project environment.

Discuss technical debt in status reporting or stand-up meetings. Stakeholders are rarely made aware of technical debt and its downstream impact. Include all team members and key stakeholders in decision-making regarding the accumulation and addressing of technical debt.