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

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Managing technical debt notes

2,713

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
2,713
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
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. 1
  • 2. Agenda 2
  • 3. About me 3
  • 4. What’s going on?• Start a little slow• Quickly pick up - A lot of features are getting developed• Things start to slow down• Can’t seem to recover• These are signs of bad code and technical debt 4
  • 5. Adding new features or simple changes take foreverPicture: http://www.flickr.com/photos/49531720@N00/247730111/ 5
  • 6. Delivery dates are missedPicture: http://www.flickr.com/photos/89306448@N00/2247180420/ 6
  • 7. Bugs increasePicture: http://www.flickr.com/photos/71962092@N00/2874328851/ 7
  • 8. Team is frustratedMorale is lowPicture: http://www.flickr.com/photos/16857236@N03/2429136239/ 8
  • 9. Customer is unhappy 9
  • 10. Uncle Bob provides the following attributes of bad code:Rigidity – difficult to change. A change causes a cascade of subsequent changes independent modules. Result -> manager fear to fix non critical problems because noreliability on impact and how long it will take. This lead to rigidity. 10
  • 11. Fragility – closely related to rigidity. Software tends to break in many places everytime it is changed. Even in areas that are conceptually unrelated. As this increases,software becomes impossible to maintain because every fix introduces 5 new bugs.This leads to distrust and a loss of credibility. 11
  • 12. Developers end up playing whack-a-bug.Picture: http://www.flickr.com/photos/tpapi/2765541278/ 12
  • 13. Immobility – inability to reuse software from other parts of the system. Need modulesimilar to another one already written, however, module has too much baggage. It ishard and risky to separate desirable part from undesirable part so decide to rewriteinstead of reuse.Picture: http://www.flickr.com/photos/97041449@N00/5261698908/ 13
  • 14. Viscosity – design (when faced with a change, take easy way(hack) or hard way)Environment-• If compile time is long, make changes that do not force large recompile• If check-in takes a long time, make as few check ins as possible• If deployment is difficult, make changes in database.• End up applying the easiest change to avoid environment issues even if change is in the wrong place. 14
  • 15. Reasons for bad code:Excuses about deadlines – no time to test, no time for design change 15
  • 16. Broken Window Theory:Police in NYC conducted a study1. Parked a car in a bad neighborhood and observed2. Nothing happened for a couple of days3. Police broke small rear window and observed4. Within 4 hours, car was strippedPicture: http://www.flickr.com/photos/7389424@N05/2351559480/ 16
  • 17. http://www.flickr.com/photos/24293932@N00/1144691293/ 17
  • 18. Broken window theory also applies to code.1. Start out and things are clean2. Once you introduce one sign of bad code, things quickly get out of handAs developers, we’ll say, well we are already doing things wrong here, so it does notmatter if we do it wrong here as well.Soon things spread and get out of control.Picture: http://www.flickr.com/photos/17454738@N00/2245445147/ 18
  • 19. Over architecting:• Attempt to envision all possible future scenarios• Create unnecessary layers of complexity to support things that are not really requirements• Tempted to design solutions to problems in advance of their needs• Program goes in a different direction and code is written without benefit• Code doesn’t really fit need because written before problem well understood• Overdesign takes extra time and produces code that is either unused or doesn’t fit the needs of the project 19
  • 20. Sometimes design is bad and instead of stopping to fix we continue building on top ofit and create an even bigger mess.Picture: http://www.flickr.com/photos/25196025@N00/381877979/ 20
  • 21. Poor skills or lack of proper training is also a major contributorhttp://www.flickr.com/photos/25507200@N07/3120849218/ 21
  • 22. Technical debt by Ward Cunningham 22
  • 23. 23
  • 24. Principal: Cost due to amount of time we need to code it the right wayInterest: Cost due to amount of extra time we spend to work with something notcoded the right wayIf it costs the same (no interest), it is just differed work and not technical debt 24
  • 25. Jim Highsmith about technical debt in terms of impact on Cost of Change 25
  • 26. We trade on quality daily. Have option to buy quality watch, but decide to buy cheaperone with out knowing what is inside. No visibility into internal quality.Picture: http://www.flickr.com/photos/39516732@N08/4666623572/ 26
  • 27. Looks the same, and cheaper!Picture: http://www.flickr.com/photos/64211362@N02/6338814898/ 27
  • 28. Martin Fowler about design stamina hypothesis:• Some benefit by ignoring good design• Soon productivity flattens out• Good design route starts out slower, but soon becomes almost linear• Intersection is design pay-off line• If above the line, no longer makes sense to ignore good design decision• Trick to know how far from line.• Martin estimates in most cases this is in magnitude of weeks not months or years 28
  • 29. Is all technical debt bad?Quick and dirty or clean? Which one would you choose?It depends… 29
  • 30. 30
  • 31. 31
  • 32. 32
  • 33. 33
  • 34. 34
  • 35. • Not all technical debt is bad• Loans to buy a house or a car are generally considered good loans• We want to be responsible in our decisions 35
  • 36. Martin Fowler introduces the technical debt quadrant:1. Inadvertent/Reckless: Don’t know that they are doing something wrong2. Deliberate/Reckless: Know it wrong and continue to do it3. Deliberate/Prudent: Make conscious decision to take on debt due to specificbusiness need4. Inadvertent/Prudent: With the best of intentions, things did not go well (rare)Most people are in quadrant 1 and 2 and we need to move them to 3.There are good reasons to take on debt like a shorter time to market, preservingstartup capital, delaying development expenses 36
  • 37. Types of debtUnintentional debt: careless mistakes, and honest mistakes (bad judgment) – never agood ideaIntentional debt – short term (focused and unfocused), long termOnly short focused and long term good debt 37
  • 38. Flower shop website must be live 2 weeks before valentines dayOtherwise business will go underMust take on debt to meet dateWill spend x weeks paying back debt while preparing for Mother’s day 38
  • 39. • Make prudent and deliberate decision on debt• Have plan to service debt• Make our payments• Avoid late payment notices 39
  • 40. We don’t want to take on debt when we are behind schedule. This causes a viciouscircle 40
  • 41. If debt not paid back, business shuts down or application will require re-writePicture: www.flickr.com/photos/66622362@N00/3353570653/ 41
  • 42. 42
  • 43. Step 1 - Register our debt• Add shortcuts decisions to technical debt backlog• Include estimated hours to do it the right way• Add date of estimate because only valid if paid off immediately 43
  • 44. 44
  • 45. 45
  • 46. We want to try to determineCost of clean wayCost of dirty waySavings nowImpact (interest rate)Cost of fix laterBeware of Broken WindowsAvoid debt that is untrackableAvoid low ROI 46
  • 47. Step 2 – Evaluate existing codeInspect and assess level of debt and also register it 47
  • 48. Sonar – open source tool 48
  • 49. Various metrics with drill down capabilities 49
  • 50. Various metrics with drill down capabilities 50
  • 51. Step 3 - monetize the debt1. Estimate the amount of hours it takes to fix each type of deficit2. Multiply by rate/hr3. Multiply by the total number of items 51
  • 52. Technical debt plugin in Sonar calculates it this way 52
  • 53. Another plugin is the SQALE metric (Software Quality Assessment based on Life CycleExpectations)that breaks things along characteristics (non functional requirements), subcharacteristics, and source code requirementsChangeability -> loose coupling or related changeability -> code duplicationMaintainability -> understandability -> redundant throws or simplifying Booleanexpressions, or unused variablesSecurity -> Errors -> preserving track trace, sql injection, or system.exitReliability - > unit test or exception handling -> unit test coverage, illegal throwsTestability -> unit level testability -> cyclomatic complexityEfficiency -> memory usage -> correct data types or static final or string bufferingPortability -> software related portability -> imports, or localeThe method defines 4 key concepts:1. The Quality Model: The SQALE Quality Model is used for formulating and organizingthe non-functional requirements that relate to code quality. It is organized in threehierarchical levels. The first level is composed of characteristics, the second of sub-characteristics. The third level is composed of requirements that relate to the sourcecode’s internal attributes. These requirements usually depend on the software contextand language. 53
  • 54. 2. The Analysis Model: The SQALE Analysis Model contains on the one hand the rulesthat are used for normalizing the measures and the violations relating to the code, andon the other hand the rules for aggregating the normalized values.3. The Indices: All indices represent costs. One represents the Technical Debt of theapplication. Others are used to analyze that debt.4. The Indicators: The method defines three summarized indicators. They have beendefined to provide a visual representation of the Technical Debt. 53
  • 55. 54
  • 56. 55
  • 57. Costs can be customized for own environmentFuture work:Prioritization, based on impact.Try to link cost vs. impact on business. Example, fixing non-initialized variable is lowcost, however, it can cause large damage 56
  • 58. 57
  • 59. 58
  • 60. With dollar amount associated with technical debt, we can engage upper managementwith a language they understand 59
  • 61. Agile Triangle by Jim Highsmith 60
  • 62. Technical debt triangle by Israel Gat 61
  • 63. Step 4 – Establish debt limitWe can now have a conversation with the business in $$$ and talk about technicaldebt and the impact on ROI.Today about 70% of an organizations IT budget is spent on maintenance instead ofnew development.What is a good amount of debt?It depends on appetite for risk.Tension between business and techBiz optimistic about benefit and the cost of carrying the debtTech pessimistic about benefit and costsKey is to manage and monitor it.If reach certain threshold, then make major payments to get back on track and keepdebt under control. 62
  • 64. Credit rating: based on teams ability to avoid unintentional technical debtAcquired debt: merger with other companies, decisions made by others90 day same as cash: if you fix it quickly there will be no interest paymentLow monthly payment: web vs. embedded software – ability to payoff debt dependson type of softwareRetiring debt: Once we retire system, there is no more debt. This is hard with financialdebtDeficit programmingTechnical Inflation: Failing behind in versions to the point where the code is no longercompatible with the compilerThe key is that technical debt enables a conversation between the technical folks andthe business folks to make informative decision on code quality 63
  • 65. Step 5 – Pay down debtWhere do we start? 64
  • 66. Tool gives us information on where to focus 65
  • 67. 66
  • 68. 67
  • 69. 68
  • 70. Step 5a – Pay high interest debt 1stDon’t quickly jump to fix most complex class. There are long term debt and short termdebt. 1st reduce short term debt which is like credit card debt.Short term debt has highest interest rate. Tackle 1st the classes that are constantlychanging the most. The more changes we make the more interest we are paying.Consider high minimum payment & required on going payment.A class with no test coverage at all, or one that is very complex, but is never or rarelymodified, needs to be left on the side for now and is considered as a low interest debt.Focus on the high interest 1st.Picture: http://www.flickr.com/photos/23327787@N08/3027534098/Picture: http://www.flickr.com/photos/37815348@N00/5398908333/ 69
  • 71. Step 5b – Pay down debt based on team skillsDoes the team know how to write tests to increase code coverage?Does the team know how to reduce complexity?If not, come up with a training and coaching plan.Does the team understand the rules they are violating? If so start their.Do they know how to remove duplications?It is going to depend, but the key is to put a plan and execute on it.Also, don’t try to many things at once. This can be overwhelming.1. Reduce debt while fixing bugs2. Do not take on additional debt for new codePicture: http://www.flickr.com/photos/51035555243@N01/155589939/ 70
  • 72. Approach:Immediately after a release10% of each iterationAbove certain thresholdRotate individual 71
  • 73. 72
  • 74. 73
  • 75. 74
  • 76. 75
  • 77. 77
  • 78. Research for this presentation based mainly on the work of Robert Martin, SteveMcConnell, Israel Gat, Martin Fowler 78
  • 79. 79
  • 80. 80
  • 81. 81
  • 82. 82
  • 83. 83

×