A Fresh Look at 'Technical Debt'

Posted by Mike Bria on Aug 27, 2008

Sections

Process & Practices,

Development

Topics

Agile ,

Delivering Quality ,

Ruby ,

Agile Techniques ,

Java

Tags

Legacy Code ,

Refactoring

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.

1. Back to top

   Yeah, I thought it was neat too -

   by Matthew Heusser

   Thanks for the coverage of the workshop.
   
   Just to add -
   
   1) Chris Sterling has some (relatively) comprehensive coverage of workshop material listed here:
   
   chrissterling.gettingagile.com/2008/08/25/the-i...
   
   Obviously, it's hard to distill two days of conference into two or three pages of text, but he makes a strong attempt.
   
   Also, we video-recorded the talks (thanks to Agile Alliance Sponsorship) and expect to have them up on youtube within a month. (Volunteer video editors of course). For the latest updates on the workshop, the best place to check is probably my blog:
   
   xndev.blogspot.com

   Reply

2. Back to top

   Technical Debt and Hackitecture

   by Anthony Lauder

   Technical debt is something I have been looking into for quite a long time. From looking into a whole bunch of software architectures, and unraveling their history, it appears that a lot of it come down to putting the best folks on an unexpected requirement to come up with a "really neat hack". The early payback on this is so great that these developers seem "10 times more productive than the average developer", so we reward hacking, and clap and
   cheer when folks do it again. Eventually, they are the only folks who can understand their own fragile lattice of hacks, and everybody else backs away from the code. Eventually, even the mental ability of these folks is overwhelmed, and you have a bankrupt hackitecture.
   
   Quite a bit of this is written up in a chapter in a book I am in the middle of writing: anthony.lauder.googlepages.com/legacysystems

   Reply

3. Back to top

   Cause of Technical debt

   by kyaw kyaw naing

   (1) lack of self discpline
   (2) impatience/hurry
   (3) ignorance.
   
   I have done a good prototype with exciting features. Then, I felt exhausted and even a bit disgusted with my own code. Heavy debts make the product ungly.
   
   You may read more at ethicminds.blogspot.com/

   Reply

4. Back to top

   technical debt in plain English

   by kyaw kyaw naing

   Technical debt is either (1) "unknown unknown" or (2) bad YAGNI(You Aint Gonna Need It), as opposed to good/official YAGNI, or clear YAGNI.
   
   See more at
   
   ethicminds.blogspot.com/2008/09/technical-debt-...

   Reply

• Older >