Technical Debt

Introduction Of Technical Debt

Technical Debt is a phrase coined by software developer, Ward Cunningham. Ward first used it to explain why resources should be used to refactor code for their financial application before deployment. He later elaborated the phrase:

With borrowed money you can do something sooner than you might otherwise, but until you pay back that money you will pay interest.

I thought borrowing money was a good idea. I thought that rushing software out the door to get some experience with it was a good idea. But that of course you would eventually go back and as you learned things about that software you would repay that loan by refactoring the program to reflect your experience as you acquired it.

Incurring Debt

The breakdown of technical debt and its categories is an ongoing discussion, but the basic premise is code that is not quite right for the task. Code can build up debt from poor structure and testing, or bad coding practices. All of these issues impact development, and can be categorized as unintentional debt. These may just sound like poor coding practices but these can just as easily result from good programmers working under unrealistic constraints. Bad code is just bad code. However technical debt doesn't only stem from mistakes, good programmers can take on debt intentionally.

Types Of Debt

My favorite categories for types of debt comes from Bill Clark, an engineering manager at Riot Games. While these are categories he applied to League of Legends for the technical debt he saw, most technical debt falls into these categories.

• Local Debt: Black box of grossness, works reliably but don't look in it.

• MacGyver Debt: "Duct-taping" systems at their interface points.

• Foundational Debt: The structure built on an assumption that may not be quite right but resonates throughout it.

• Data debt: Data piled onto other debts making it risky and time-consuming to fix.

Intentional Debt - Technical Debt Is Not All "Bad"

While the term debt sounds inherently bad, similarly to Ward's comparison to borrowing money, if used properly it can be a tool. Technical debt can be taken on purposely when taking shortcuts in writing code to achieve your goal faster, whether that goal is to ship out your product quickly or meet a customer deadline.

Paying Back The Debt

The solution to pay back the debt, just like every piece of technical debt is different. Bill Clark broke down paying back the debt into 3 major parts to evaluate.

1. Impact - The impact of the debt can take form in both customer issues and developer issues. For customers it can be bugs, missing features or unexpected behaviors. For the developers it can range from slower implementation to workflow issues.
2. Fix Cost - Fixing an issue will cost someones time. Whether it can be fixed in a few minutes to weeks or months, there is a risk to implementing a fix. Something that may be "wrong" can be in use somewhere else and break something else.
3. Contagion - If this technical debt continues, how much will it affect? Will it influence the way other developers choose to implement new things?