Live from Agile 2013

Great session this morning on technical debt, led by Israel Gat. If you haven’t seen him run through this deck I recommend you look for a video. Excerpts below.

Technical Debt Ratio

Technical debt is a monetary value for non-quality in software. When teams look at this they want to figure out what their debt ratio is, similar to when you purchase a house and look at the debt ratio (equity in your house vs the mortgage).

Israel showed off a neat dashboard gadget that listed a products debt ratio, mortgage value in $, work days to paydown the debt and a breakdown by complexity. I need to chase up with him to see what product provided that gadget.

The time a team spends working on technical debt is a missed opportunity to work on features and deliver value to their customer. And, of course, you pay interest on that debt so long as you have it. Technical debt turns code into a liability, not an asset (TD+C<V).

Israel talks of three types portions of the mortgage – the principal, the recurring interest, and the compound interest. Think of the first two as the regular stuff you have with a mortgage. The third one, compound interest, comes into effect primarily when you copy and paste code leading to a multiplicative expansion in the code that needs to be maintained.

Teams can measure technical debt using:

• Principal – test coverage, code duplication, cyclomatic complexity
• Recurring Interest – support cases, product maintenance
• Compounding Interest – growth in Principal over time

Pay Down Technical Debt

Before you start tackling technical debt you should make sure added / updated code is under control. Address the root cause – train the team so they don’t write code with high technical debt in future.

Technical debt is a vicious cycle, the longer we leave it the more we accrue, the slower the process is. Decreasing team velocity and happiness. One approach is to manage software delivery through WIP limits.

Don’t start by paying off legacy debt. Instead, start by training teams to write better code, allowing then to write better new code and also refactor existing code more effectively.

May get more value from focusing on paying down compounding interest first, due to its exponential effect. Then move on to recurring interest. However, you may want to reverse the approach this if the company’s cash flow doesn’t provide a buffer enabling the team to await for a reduction in duplicate code.

Outcomes

Process is just a thing teams and organisations use to deliver code (output). The real value though is the outcome, the value delivered to the customer. If you build up technical debt, you deliver less value to the customer.

Great visual:

Takeaway

Is it a methodology, a business, or and operational issue?

Remember, technical debt is not the problem, it is a symptom. Find the root cause, which is most often the teams experience and approach to developing software. Sometimes the root cause may be the company trying to do too much work at once, or not allowing the teams to find and maintain a sustainable pace.

Like this? Follow Israel Gat and react on Twitter:

Technical Debt meets Agile http://t.co/FokZFvR0CD

— Nicholas Muldoon (@njm) August 8, 2013