A Fresh Look at 'Technical Debt'

A Technical Debt Workshop was recently held to improve our industry's understanding of and approach to "technical debt", resulting in some interesting ideas. Among them, changing our perception of the problem to focus on "assets" rather than "debt", an idea now receiving quite a bit of attention by people such as Michael Feathers and Brian Marick.

The conference organizers Matt Heusser and Steve Poling presented the vision for the 2-day event as follows:

A successful meeting will identify specific metrics that will bring the discussion of technical debt down to earth. It will also marshal evidence that we're not fooling ourselves when we say that borrowed trouble behaves like borrowed money. (Or better, we prove another dynamic is in play.) It will also state debt management and debt repayment strategies and when they are indicated.

The conference aimed to answer these 3 primary questions:

1. What is technical debt? And what is not?
2. How do we measure it? And its impact?
3. Can we manage technical debt like other forms of debt?

The event surfaced some interesting ideas, as summarized by Heusser:

• Ignorance: Bad code can birth from either sheer ignorance and/or as a result of a conscious decision. Read more on this from Brian Marick.
• Bug Fixin': Bugs must always be fixed as soon as discovered; foster a stop-the-line culture.
• Moral Hazard: When the lack of adequate customer-influence on the team leads to hazardously speedy but lower quality development, a concept introduced by Heusser
• Impedance Mismatch: The possible negative effect on code quality of mismatching developer skill with difficulty of development task. More on this from Chris McMahon.
• Liquid Assests: Perhaps the term "technical debt" focuses us on the wrong things; maybe focusing on the converse, on the investment side of things (as McMahon recently put it), might be more effective.
• Affordances: Prove the team with regular time to reduce technical debt, and thus "increase assets".

Perhaps most interesting, or least fresh, of the ideas above is thinking of technical debt from the other perspective: striving to "increase assets". In other words, speaking in the Accounting 101 sense of "debits & credits": one can focus on reducing debits or on increasing credits, but in the end the ideal goal is simply to increase assets. It's in some ways a matter of perspective.

Just before the event Michael Feathers had written about the "code as an asset" idea. His point largely being that seeing code from an "asset" perspective might tap into more desirable points of people's nature, leading to a better result with respect to code quality and reaction to "technical debt" problems. According to Feathers, this aligns better because people naturally like gaining things ("assets"), not losing things ("debt").

Brian Marick later continued the discussion, using the term "fertile assets" to describe the effect of code quality on sustainable development. He draws an analogy to gardening, explaining that soil must remain fertile for continued harvests, but even so cannot necessarily always be of absolute top-level fertility as that would ultimately prevent harvesting. His observation is that production code behaves in a similar fashion.

One additional brief but rather interesting write-up coming out of the workshop, also by Brian Marick, highlights descriptions from some well-known agilistas of what’s unique about a typical decreasing-debt team.

As always, please do follow the links to get the full story on what's summarized here, then come back and others what your experience has led you to think about these ideas. 4 comments