Managing Technical Debt


Published on

Given by Steve Ropa. Using agile and agile tools to manage risk and deliver better software faster.

Published in: Economy & Finance, Business
1 Comment
  • Hi
    Great presentation.
    You should have a look at the SQALE indicators which support different pay back strategies depending on your goal and available budget:
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Managing Technical Debt

  1. 1. © 2011 VersionOne 1Managing TechnicalDebt
  2. 2. © 2011 VersionOne 2Let’s Talk
  3. 3. © 2011 VersionOne 3What is Technical Debt• Design Compromises• Choosing to accept something as “done” before its time
  4. 4. © 2011 VersionOne 4Technical debt is not always represented byDefectspublic void populateList(String food){Food SelectedFood = new Food();if(food.equalsIgnoreCase("vegetable")){SelectedFood = new Vegetables();}else if(food.contains("Legume")){SelectedFood = new Legume();}list.setAdapter(mSchedule);}
  5. 5. © 2011 VersionOne 5But it usually results in them
  6. 6. © 2011 VersionOne 6Is technical debt always bad?• Just as in finance, sometimes taking on a certain level ofdebt can be considered an investment.– This needs to be a decision that is made proactively, notreactively
  7. 7. © 2011 VersionOne 7Is a debt free project even possible?• Mentality of Sufficiency – Perfect is the natural enemyof Good
  8. 8. © 2011 VersionOne 8When might debt be ok?• New architecture– Perhaps we want to do our migration to the new architecture onestep at a time. Until we have completed the migration we arechoosing debt• First to Market– Sometimes, the monetary effect of being first to market is worthincurring some debt
  9. 9. © 2011 VersionOne 9Some common ways to incur debt• Time pressure– We don’t have enough time to finish, unless we cut some corners• Competitive pressure– If we can at least show this feature, we will beat the competitorto market
  10. 10. © 2011 VersionOne 10How might we avoid taking on too muchdebt?
  11. 11. © 2011 VersionOne 11Test Driven Development
  12. 12. © 2011 VersionOne 12Acknowledging the interest rate• There is a cost to waiting• Understand what that cost is and call it out• Remember that interest compounds
  13. 13. © 2011 VersionOne 13Paying off inherited debt (legacy code)• Start small, creating tests around any work we do withinthe legacy code base• We own this debt just as much any debt we choose totake on.
  14. 14. © 2011 VersionOne 14Refactoring – paying a little at a time• All debt has a minimum payment, or “debt service”• We can pay our debt service through improving the designwhenever we are in our code, without changing thebehavior– Find a place that could use some improvement– Wrap the change in tests– Make the change– Run the tests• Its ok to pay a little extra, but don’t go overboard
  15. 15. © 2011 VersionOne 15Some strategies for spending within yourmeans• Keep your stories small• Only sign up for what you can comfortably accomplish• Stick to your guns, only agree to debt that you can becomforatable with
  16. 16. © 2011 VersionOne 16Don’t take on more than you can pay
  17. 17. © 2011 VersionOne 17Limited WIP and Kanban• By constraining how much work we take on at one timewe can focus on quality• Pull oriented processes mean less incentive to “cramsomething in”
  18. 18. © 2011 VersionOne 18Iterative Development and Velocity• As we identify a cadence and velocity, we see how muchwe really can sign on for• Tight feedback loops give us room to inspect and adapt
  19. 19. © 2011 VersionOne 19Pay the Biggest interest items first• Make debt service on all debt• As you fix the more expensive items, you are freeing upresources for the less expensive items later
  20. 20. © 2011 VersionOne 20Debt Restructuring• Sometimes, but *very* seldom, we have to declarebankruptcy – Major Rearchitecture• A better approach is to create a restructuring plan• A set of payments (backlog items or defects) that arescheduled at regular intervals, and with higher priority orClass of Service than new features
  21. 21. © 2011 VersionOne 21Alternative ways to consider debt• Choose a metaphor that resonates• Not everyone is comfortable with the money theme
  22. 22. © 2011 VersionOne 22Speedboat• Our product is a speedboat, heading for an exotic harbor• Our debt is a set of anchors– Each anchor has a weight associated with the amount of workto be done– Each anchor is a different depth, loosely analogous to how long itwill take to pull the anchor up
  23. 23. © 2011 VersionOne 23Some basic tips
  24. 24. © 2011 VersionOne 24Recognize your debt• Don’t sweep it under the rug• “It goes without saying” doesn’t
  25. 25. © 2011 VersionOne 25“Borrow” only when absolutely necessary• Don’t let It become a habit• By thinking of it as a necessary evil, we can make itsomething that is an exception instead of a rule
  26. 26. © 2011 VersionOne 26Track debt• Note the “interest rate”• Calculate the costs at periodic intervals
  27. 27. © 2011 VersionOne 27Plan to pay your debt, just like you plan fornew features
  28. 28. © 2011 VersionOne 28Don’t beat yourself up• We all borrow• Sometimes we let our borrowing get away from us• Recriminations do NOTHING to get the debt paid off
  29. 29. © 2011 VersionOne 29Remember, you can pay me now, or you canpay me later…