Managing technical debt

6,710 views

Published on

1 Comment
8 Likes
Statistics
Notes
  • Very nice explanations, Fadi. Visitors may be interested also in how to get rid of debt "on the fly": http://tinyurl.com/kpv9mrk
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
6,710
On SlideShare
0
From Embeds
0
Number of Embeds
3,572
Actions
Shares
0
Downloads
0
Comments
1
Likes
8
Embeds 0
No embeds

No notes for slide

Managing technical debt

  1. 1. Managing Technical Debt Managing Technical DebtFadi StephanFadi.Stephan@excella.com@FadiStephanExcella.comAgileJourneyman.com
  2. 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. 3. What’s Going On?454035302520 Velocity151050 1 2 3 4 5 6 7 8 9 10 11 12
  4. 4. Rigidity
  5. 5. Immobility
  6. 6. Viscosity
  7. 7. Deadline
  8. 8. Broken Window
  9. 9. Over Architecting
  10. 10. Bad Design
  11. 11. Poor Skills
  12. 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. 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. 14. Quick and dirty design results in Principal Interest Technical Debt
  15. 15. Trading for Quality
  16. 16. Design Stamina Hypothesis martinfowler.com/bliki/DesignStaminaHypothesis.html
  17. 17. Which one will you choose? 1. Quick and Dirty 2. Clean
  18. 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. 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. 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. 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. 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. 23. Home or car loan
  24. 24. Technical Debt Quadrant martinfowler.com/bliki/TechnicalDebtQuadrant.html
  25. 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. 26. theagileexecutive.com/category/technical-debt
  27. 27. Technical Debt Management Plan
  28. 28. Register the Debt
  29. 29. Date: 2/10/2012 Estimate: 3 As I prudent developer, I am deliberately taking on technical debt by … … so that… Impact: M
  30. 30. Estimate: 8As I prudent developer,I want to refactor ….……so that I can repay the technical debt
  31. 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. 32. Evaluate Code BaseComplexityCode CoverageDuplicationRule ViolationsDesign
  33. 33. Monetize the DebtTechnical Debt = #items * #hours/item * $/hr
  34. 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. 35. SQALE Changeability Maintainability Security Reliability Testability Efficiency Portability
  36. 36. sqale.org/wp-content/uploads/2012/04/SQALE-3RD-WS-on-MTD.pdf
  37. 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. 38. SQALE Pyramid sqale.org/wp-content/uploads/2012/04/SQALE-3RD-WS-on-MTD.pdf
  39. 39. History
  40. 40. Cost = 2,000,000Profit=10,000,000Debt =3,000,000ROI = (10M – 2M)/ 2M = 400% theagileexecutive.com/category/technical-debt/
  41. 41. theagileexecutive.com/tag/the-agile-triangle/
  42. 42. 10,000,0003,000,000 2,000,000 ROI = (10M – (2M + 3M))/ 5M = 100% theagileexecutive.com/tag/the-agile-triangle/
  43. 43. How much debt is too much debt?
  44. 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. 45. Paying Down The Debt
  46. 46. Pay debt with high interest rate 1st
  47. 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. 48. SummaryManaging technical debt requires that we makeprudent and deliberate decision ondesign & quality
  49. 49. SummaryProvide transparency by 1. Registering any new debt 2. Assessing existing debt
  50. 50. SummaryInspect by 1. Monetizing the debt 2. Establishing a debt limit 3. Monitor trends
  51. 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. 52. AgileJourneyman.com@FadiStephan
  53. 53. AcknowledgementRobert Martin Steve McConnell Israel Gat Martin Fowler
  54. 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. 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. 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. 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. 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/

×