A Fresh Look at 'Technical Debt'
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.
Yeah, I thought it was neat too -
Just to add -
1) Chris Sterling has some (relatively) comprehensive coverage of workshop material listed here:
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:
Technical Debt and Hackitecture
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
kyaw kyaw naing
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
kyaw kyaw naing
See more at