3. About Fadi Stephan
• 15+ years of experience in
software development
• Focused on Agile since
2006
• Consultant with Excella
• Founder of the DC
Software Craftsmanship
User Group
• Organizer of the DC Scrum
User Group
22. Technical Debt
“Shipping first time code is like going
into debt. A little debt speeds
development so long as it is paid back
promptly with a rewrite... The danger
occurs when the debt is not repaid.
Every minute spent on not-quite-right
code counts as interest on that debt.”
- Ward Cunningham
23. Technical Debt Metaphor
“Neglecting the design is like borrowing money”
“Developing slower because of this debt is like paying
interest on the loan”
“Refactoring, it's like paying off the principal debt”
“Every minute spent on not-quite-right code counts as
interest on that debt”
24. Quick and dirty design results in
Principal
Interest
Technical Debt
30. Managing Technical Debt
Given the option between a clean or dirty approach, which one will you choose?
1. Team, this past sprint our velocity was down due to a lot of time spent on UI
issues. Let’s not worry about compatibility with other browsers and just write
enough code to make the application work in IE 8. Don’t worry if the code breaks
things on the other browsers. Our corporate policy is for us to support IE 8 only.
2. Team, we are behind schedule. We need to catch up quickly. Let’s skip unit
testing for now and just get the code working. We’ll come back and write the tests
after we release. The business is counting on us!
3. I think it now makes more sense to have the EMAIL field is the EMPLOYEE table
instead of the ATTRIBUTE table. We don’t have time to change the code, but we
can create a trigger for now to keep the two database tables in sync and we’ll
refactor the code after we release.
4. This story has a bunch of rules that need to be validated in the business layer. It
will probably take 40 hours to do. However, I can write the same logic in the UI
layer a lot quicker. I think I can wrap this up in about 8 hours. I’ll be able to move
the code to the business layer in a future sprint when I have more time.
31. Case 1
Team, this past sprint our velocity was down due
to a lot of time spent on UI issues. Let’s not
worry about compatibility with other browsers
and just write enough code to make the
application work in IE 8. Don’t worry if the code
breaks things on the other browsers. Our
corporate policy is for us to support IE 8 only.
32. Case 2
Team, we are behind schedule. We need to
catch up quickly. Let’s skip unit testing for now
and just get the code working. We’ll come back
and write the tests after we release. The
business is counting on us!
33. Case 3
I think it now makes more sense to have the
EMAIL field is the EMPLOYEE table instead of the
ATTRIBUTE table. We don’t have time to change
the code, but we can create a trigger for now to
keep the two database tables in sync and we’ll
refactor the code after we release.
34. Case 4
This story has a bunch of rules that need to be
validated in the business layer. It will probably
take 40 hours to do. However, I can write the
same logic in the UI layer a lot quicker. I think I
can wrap this up in about 8 hours. I’ll be able to
move the code to the business layer in a future
sprint when I have more time.
37. Types of Debt
• Unintentional
• Intentional
– Short term & focused
– Short term & unfocused
– Long term
• Only short term focused debt & long term
debt are “good” debt
forums.construx.com/blogs/stevemcc/archive/2007/11/01/technical-debt-2.aspx
56. Sample Remediation Functions
Requirement Remediation Details Remediation
Function
No commented out Remove 1 min/occurrence
blocks
At least 70% code Write tests 20 min/per
coverage uncovered line
Code overrides both Write code and tests 1 hr/occurrence
equals and hashcode
sqale.org/wp-content/uploads/2012/04/SQALE-3RD-WS-on-MTD.pdf
63. Metaphor
• Think of 3 more examples of ways to use the
technical debt metaphor
– Analogy 1:
– Analogy 2:
– Analogy 3:
• Do you think the technical debt metaphor
works well?
• If not, why?
70. Approach
• Have a technical debt reduction sprint
immediately after a release
• Have a technical debt reduction sprint once
we reach a certain limit
• Rotate dedicated members to work on
reducing technical debt
• Dedicate 10% of each sprint to reducing
technical debt
• Reduce technical debt by story
73. Summary
Inspect by
1. Monetizing the debt
2. Establishing a debt limit
3. Monitor trends
74. Summary
Adapt by
1. Paying down the debt focusing on high
interest rate 1st.
2. Starting with what you know. Train for the
rest
3. Continuously monitor the debt
77. References
• Design Principles and Design Patterns - Robert Martin
• Design Stamina Hypothesis -
martinfowler.com/bliki/DesignStaminaHypothesis.html
• Technical Debt Quadrant -
martinfowler.com/bliki/TechnicalDebtQuadrant.html
• The Agile Triangle –
theagileexecutive.com/tag/the-agile-triangle/
• Technical Debt Assessment and Reduction –
theagileexecutive.com/category/technical-debt/
• Technical Debt, Cutter IT Journal October 2010 -
www.cutter.com
78. References
• Technical Debt A Perspective for Manager –
www.infoq.com/articles/technical-debt-levison
• Managing Technical Debt -
blogs.versionone.com/agile_management/2011/07/11/managing-technical-debt/
• What Testers Can Do About Technical Debt -
www.stickyminds.com/sitewide.asp?ObjectId=3629
• Climb Out of Technical Debt –
www.ayeconference.com/climboutoftechnicaldebt/
• Don't Live with Broken Windows –
www.artima.com/intv/fixit.html
79. References
• Technical Debt -
forums.construx.com/blogs/stevemcc/archive/2007/11/01/technical-debt-
2.aspx
• Sonar –
http://www.sonarsource.org/evaluate-your-technical-debt-with-sonar/
• Pay Down your Technical Debt –
www.codinghorror.com/blog/2009/02/paying-down-your-technical-debt.html
• SQALE Method For Evaluating Technical Debt –
http://www.sqale.org/wp-content/uploads/2012/04/SQALE-3RD-WS-on-MTD.pdf
