Your SlideShare is downloading. ×
Managing technical debt
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Managing technical debt

4,685
views

Published on


1 Comment
7 Likes
Statistics
Notes
No Downloads
Views
Total Views
4,685
On Slideshare
0
From Embeds
0
Number of Embeds
11
Actions
Shares
0
Downloads
0
Comments
1
Likes
7
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Managing Technical Debt Managing Technical DebtFadi StephanFadi.Stephan@excella.com@FadiStephanExcella.comAgileJourneyman.com
  • 2. 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
  • 3. What’s Going On?454035302520 Velocity151050 1 2 3 4 5 6 7 8 9 10 11 12
  • 4. Rigidity
  • 5. Immobility
  • 6. Viscosity
  • 7. Deadline
  • 8. Broken Window
  • 9. Over Architecting
  • 10. Bad Design
  • 11. Poor Skills
  • 12. Technical Debt“Shipping first time code is like goinginto debt. A little debt speedsdevelopment so long as it is paid backpromptly with a rewrite... The dangeroccurs when the debt is not repaid.Every minute spent on not-quite-rightcode counts as interest on that debt.” - Ward Cunningham
  • 13. Technical Debt Metaphor“Neglecting the design is like borrowing money”“Developing slower because of this debt is like payinginterest on the loan”“Refactoring, its like paying off the principal debt”“Every minute spent on not-quite-right code counts asinterest on that debt”
  • 14. Quick and dirty design results in Principal Interest Technical Debt
  • 15. Trading for Quality
  • 16. Design Stamina Hypothesis martinfowler.com/bliki/DesignStaminaHypothesis.html
  • 17. Which one will you choose? 1. Quick and Dirty 2. Clean
  • 18. Managing Technical DebtGiven 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 UIissues. Let’s not worry about compatibility with other browsers and just writeenough code to make the application work in IE 8. Don’t worry if the code breaksthings 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 unittesting for now and just get the code working. We’ll come back and write the testsafter we release. The business is counting on us!3. I think it now makes more sense to have the EMAIL field is the EMPLOYEE tableinstead of the ATTRIBUTE table. We don’t have time to change the code, but wecan create a trigger for now to keep the two database tables in sync and we’llrefactor the code after we release.4. This story has a bunch of rules that need to be validated in the business layer. Itwill probably take 40 hours to do. However, I can write the same logic in the UIlayer a lot quicker. I think I can wrap this up in about 8 hours. I’ll be able to movethe code to the business layer in a future sprint when I have more time.
  • 19. Case 1Team, this past sprint our velocity was down dueto a lot of time spent on UI issues. Let’s notworry about compatibility with other browsersand just write enough code to make theapplication work in IE 8. Don’t worry if the codebreaks things on the other browsers. Ourcorporate policy is for us to support IE 8 only.
  • 20. Case 2Team, we are behind schedule. We need tocatch up quickly. Let’s skip unit testing for nowand just get the code working. We’ll come backand write the tests after we release. Thebusiness is counting on us!
  • 21. Case 3I think it now makes more sense to have theEMAIL field is the EMPLOYEE table instead of theATTRIBUTE table. We don’t have time to changethe code, but we can create a trigger for now tokeep the two database tables in sync and we’llrefactor the code after we release.
  • 22. Case 4This story has a bunch of rules that need to bevalidated in the business layer. It will probablytake 40 hours to do. However, I can write thesame logic in the UI layer a lot quicker. I think Ican wrap this up in about 8 hours. I’ll be able tomove the code to the business layer in a futuresprint when I have more time.
  • 23. Home or car loan
  • 24. Technical Debt Quadrant martinfowler.com/bliki/TechnicalDebtQuadrant.html
  • 25. 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
  • 26. theagileexecutive.com/category/technical-debt
  • 27. Technical Debt Management Plan
  • 28. Register the Debt
  • 29. Date: 2/10/2012 Estimate: 3 As I prudent developer, I am deliberately taking on technical debt by … … so that… Impact: M
  • 30. Estimate: 8As I prudent developer,I want to refactor ….……so that I can repay the technical debt
  • 31. Technical Debt BacklogStory Dirty Clean On Date Estimate Estimate Going Impact… 3 8 H 2/5/2012… 1 5 M 2/10/2012… 3 13 L 2/11/2012
  • 32. Evaluate Code BaseComplexityCode CoverageDuplicationRule ViolationsDesign
  • 33. Monetize the DebtTechnical Debt = #items * #hours/item * $/hr
  • 34. Technical Debt PluginDebt(in man days) = cost_to_fix_duplications + cost_to_fix_violations + cost_to_comment_public_API + cost_to_fix_uncovered_complexity + cost_to_bring_complexity_below_threshold + cost_to_cut_cycles_at_package_level
  • 35. SQALE Changeability Maintainability Security Reliability Testability Efficiency Portability
  • 36. sqale.org/wp-content/uploads/2012/04/SQALE-3RD-WS-on-MTD.pdf
  • 37. Sample Remediation FunctionsRequirement Remediation Details Remediation FunctionNo commented out Remove 1 min/occurrenceblocksAt least 70% code Write tests 20 min/percoverage uncovered lineCode overrides both Write code and tests 1 hr/occurrenceequals and hashcode sqale.org/wp-content/uploads/2012/04/SQALE-3RD-WS-on-MTD.pdf
  • 38. SQALE Pyramid sqale.org/wp-content/uploads/2012/04/SQALE-3RD-WS-on-MTD.pdf
  • 39. History
  • 40. Cost = 2,000,000Profit=10,000,000Debt =3,000,000ROI = (10M – 2M)/ 2M = 400% theagileexecutive.com/category/technical-debt/
  • 41. theagileexecutive.com/tag/the-agile-triangle/
  • 42. 10,000,0003,000,000 2,000,000 ROI = (10M – (2M + 3M))/ 5M = 100% theagileexecutive.com/tag/the-agile-triangle/
  • 43. How much debt is too much debt?
  • 44. 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?
  • 45. Paying Down The Debt
  • 46. Pay debt with high interest rate 1st
  • 47. 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
  • 48. SummaryManaging technical debt requires that we makeprudent and deliberate decision ondesign & quality
  • 49. SummaryProvide transparency by 1. Registering any new debt 2. Assessing existing debt
  • 50. SummaryInspect by 1. Monetizing the debt 2. Establishing a debt limit 3. Monitor trends
  • 51. SummaryAdapt 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
  • 52. AgileJourneyman.com@FadiStephan
  • 53. AcknowledgementRobert Martin Steve McConnell Israel Gat Martin Fowler
  • 54. 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
  • 55. 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/• Dont Live with Broken Windows – www.artima.com/intv/fixit.html
  • 56. 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
  • 57. Pictures• http://www.flickr.com/photos/49531720@N00/247730111/• http://www.flickr.com/photos/89306448@N00/2247180420/• http://www.flickr.com/photos/71962092@N00/2874328851• http://www.flickr.com/photos/16857236@N03/2429136239• http://www.flickr.com/photos/tpapi/2765541278/• http://www.flickr.com/photos/97041449@N00/5261698908/• http://www.flickr.com/photos/7389424@N05/2351559480/• http://www.flickr.com/photos/24293932@N00/1144691293/• http://www.flickr.com/photos/17454738@N00/2245445147/
  • 58. Pictures• http://www.flickr.com/photos/25196025@N00/381877979/• http://www.flickr.com/photos/25507200@N07/3120849218/• http://www.flickr.com/photos/39516732@N08/4666623572/• http://www.flickr.com/photos/64211362@N02/6338814898/• http://www.flickr.com/photos/66622362@N00/3353570653/• http://www.flickr.com/photos/23327787@N08/3027534098/• http://www.flickr.com/photos/37815348@N00/5398908333/• http://www.flickr.com/photos/51035555243@N01/155589939/