Successfully reported this slideshow.
Upcoming SlideShare
×

# Measuring technical debt

6,197 views

Published on

David Simner talks about some ways for measuring technical debt, and why it's important to choose the right ones in your team. He introduces the idea of story probing to see how fixing technical debt changes your scrum story estimates.

See more at http://dev.red-gate.com/lightning-talks

• Full Name
Comment goes here.

Are you sure you want to Yes No
• Be the first to comment

### Measuring technical debt

1. 1. Measuring technical debt (and why it matters)
2. 2. 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
3. 3. 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
4. 4. Metric 1 • C# compiler errors & warnings: • Ideal = 0 • Reality =
5. 5. Metric 2 • R# errors: • Ideal = 0 • Reality =
6. 6. Metric 3 • Amount of code duplication: • Ideal = 0 • Reality = 58 exact matches, 75 strong matches, 179 medium matches, and 191 weak matches
7. 7. Metric 4 • Unit test coverage: • Ideal = ? • Reality = • Better =
8. 8. 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
9. 9. 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
10. 10. Measurement approach 2: Story probing • Firstly, you need: • A story • Or, some stories • They can be from the backlog • Or, even hypothetical
11. 11. 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
12. 12. 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
13. 13. 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
14. 14. 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…?