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:
- What is technical debt? And what is not?
- How do we measure it? And its impact?
- Can we manage technical debt like other forms of debt?
- 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".
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.
Community comments
Yeah, I thought it was neat too -
by Matthew Heusser,
Technical Debt and Hackitecture
by Anthony Lauder,
Cause of Technical debt
by kyaw kyaw naing,
technical debt in plain English
by kyaw kyaw naing,
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
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
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/
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-...