BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ
News Articles Presentations Podcasts Guides

Topics

Choose your language

QCon New York

Find real-world practical inspiration from the world’s most innovative software leaders. Attend in-person or online.
QCon San Francisco

Learn what's next in software from world-class leaders pushing the boundaries. Attend in-person or online.
The Software Architects' Newsletter

Your monthly guide to all the topics, technologies and techniques that every professional needs to know about. Subscribe for free.

InfoQ Homepage News A Fresh Look at 'Technical Debt'

QCon New York (June 13-15): Learn best practices from senior developers at early adaptor companies.

A Fresh Look at 'Technical Debt'

This item in japanese

Bookmarks

Aug 27, 2008 2 min read

Write for InfoQ

Join a community of experts. Increase your visibility.
Grow your career.Learn more
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.

Rate this Article

Adoption
Style

This content is in the Software Craftsmanship topic

Related Topics:

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Yeah, I thought it was neat too -

    by Matthew Heusser,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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

    Back to top
  • Technical Debt and Hackitecture

    by Anthony Lauder,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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

    Back to top
  • Cause of Technical debt

    by kyaw kyaw naing,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    (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/

    Back to top
  • technical debt in plain English

    by kyaw kyaw naing,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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-...

    Back to top

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT