Measuring

technical debt

(and why it

matters)

You get what you measure• We need to keep this in mind

when measuring technical debt, so that when we make strides to pay back our technical debt, that time investment is actually worth it

Measurement approach 1:The delta from ideal• You define a whole bunch of

metrics where:• You know what ideal looks like• You know what reality looks like

• Then you see how you score

Metric 1

• C# compiler errors & warnings:• Ideal = 0• Reality =

Metric 2

• R# errors:• Ideal = 0• Reality =

Metric 3

• Amount of code duplication:• Ideal = 0• Reality = 58 exact matches, 75

strong matches, 179 medium matches, and 191 weak matches

Metric 4

• Unit test coverage:• Ideal = ?• Reality =

• Better =

Metric 5

• Gut feeling:• Ideal = amazing• Reality =

• Unlike the previous 4, this can’t be measured automatically

463 lines

8,999 lines

7,765 lines

4,725 lines

However…

• You need to pick the metrics carefully• Otherwise there’ll be a high opportunity

cost to your fixing

• In a large application with lots of technical debt, this measure is basically useless• There will be an insurmountable delta

between ideal and reality

Measurement approach 2:Story probing• Firstly, you need:

• A story• Or, some stories

• They can be from the backlog• Or, even hypothetical

Measurement approach 2:Story probing (continued)• Then, you estimate them• Just as you Scrum has taught us

to:• 1, 2, 3, 5, 8, 13, 20

Measurement approach 2:Story probing (finally)• The assumption is that technical debt

increases the estimate• You can re-estimate in the future, to

see if technical debt is getting worse• Or, you can re-estimate after real or

hypothetical refactorings, to see if the technical debt is actually reduced

Measurement approach 2:Story probing (corollaries)• One way to reduce the estimate

(and hence the technical debt) is to leave the code alone (and therefore keep it in its utterly terrible state), but to aid the team’s understanding of the code

However…

• Imagine the estimate used to be 5• After some refactoring, it’s now 3• What does that mean in practice?• What are the errors bars?• Before: 5 ± 2• After: 3 ± 2• Is it actually any better…?