In the current age of software development the phrase "technical debt" has become part of the common vocabulary. Wikipedia defines technical debt as "a neologistic metaphor referring to the eventual consequences of poor or evolving software architecture and software development within a codebase." Buried within this eloquent statement is a clear dividing line. There are two distinct types of technical debt: strategic and non-strategic. Technical debt is commonly compared to credit card debt, as the interest of unpaid debt can become stifling. Proper tracking and categorization of this debt helps avoid technical bankruptcy. This happens when a team can no longer make forward progress due to ongoing debt derailments. Framing technical debt, making it visible, and arguing for its maintenance is paramount.

Strategic debt is intentional debt accumulated in a project. They are conscious, proactive decisions with larger short term benefits. This debt focuses on architectural and/or business trade-offs. Deciding to forgo extensive architecture for increased speed to market or reduce overhead is intentional debt. Small companies and new unproven products utilize this concept to keep costs down or to increase innovation. Other companies utilize strategic debt to maintain customer satisfaction or to meet project deadlines. The two most common reasons for strategic debt are time and/or money.

Non-strategic debt is unintentional debt accumulated in a project. This debt can happen when a feature is poorly designed or coded. Error-prone code creates more maintenance during the QA process and potentially more customer issues once deployed. Programming may also loose its effectiveness due to a lack of communication or concepts lost in translation. Unfortunately, this debt is unknown to most participants until after it has been created. Programmers do not knowingly design or write ineffective code.

The decision to tackle non-strategic debt is based on three factors: when it was found, the size of the problem, and where the problem is located. Once an area has been identified as non-strategic debt, the decision to forgo correcting the situation can become strategic.

Although strategic debt in a product can grow and shrink over time, non-strategic debt has a tendency to increase as a team grows. This increase can be accounted for through proper oversight. This can translate into new procedural steps, coding standards, code reviews, retrospectives, and much more. Each company is different. It's important to keep a continuous eye on strategic debt. Initial estimates of the size and time line can be affected by other business decisions or unanticipated customer growth. Strategic debt only becomes a problem when it is not properly monitored.

Note: There is no definitive definition of what is and is not technical debt. Outside of the previous paragraphs, some consider smaller differences such as not following coding standards or a lack of commenting to be technical debt. Although each company is different, the need for categorization and prioritization remains the same.

Technical Debt: Strategic vs. Non-Strategic