Technical Debt

The metaphor of technical-debt was first expressed by Ward Cunningham in 1992:

Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.

Like many other experienced software developers, I’ve seen, created and addressed my share of technical debt during my career. These posts cover some of my thoughts on the subject, including some ideas on the different kinds of technical debt and the different ways they can be mitigated or avoided.

Temporal Technical Debt

Saturday, September 05 2015 technical-debt

By this stage, I guess that most developers are aware of the concept of “Technical Debt” as coined by Ward Cunningham in 1992 when he wrote:

Accidental Technical Debt

Sunday, September 13 2015 technical-debt

Continuing from last week’s post on temporal technical debt I want to continue the discussion by talking about Accidental Technical Debt.

More On Accidental Technical Debt

Sunday, October 04 2015 technical-debt

Feedback on my post about accidental technical debt, including a great comment from Brian Willis has highlighted two additional mitigation techniques that I omitted from the original post - Code Reviews and Interactive Development.

Technological Technical Debt

Sunday, October 11 2015 technical-debt

While in many ways a subset of temporal technical debt, the impact of unaddressed technological debt is significant enough that it’s worth breaking out as a separate category.

Intentional Technical Debt

Sunday, October 25 2015 technical-debt

Intentional Technical Debt is when you make an informed decision to take on some technical debt in order to achieve a more important goal. The key factor here is that the decision must be an informed one, not forgetting the need to handle the consequences of that decision and taking known risk factors into account.

The Maintainability Metric

Sunday, November 22 2015 technical-debt

As a metaphor, Technical Debt gives us a useful way to think about certain problems. How can we now try to measure it and ensure that we are improving things, not making them worse?