• Save
Managing Technical Debt
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Managing Technical Debt

  • 604 views
Uploaded on

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

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

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • 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:
    http://www.sqale.org/blog/the-sqale-pyramid-a-powerful-indicator
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
604
On Slideshare
604
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
1
Likes
2

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. © 2011 VersionOne 1Managing TechnicalDebt
  • 2. © 2011 VersionOne 2Let’s Talk
  • 3. © 2011 VersionOne 3What is Technical Debt• Design Compromises• Choosing to accept something as “done” before its time
  • 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. © 2011 VersionOne 5But it usually results in them
  • 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. © 2011 VersionOne 7Is a debt free project even possible?• Mentality of Sufficiency – Perfect is the natural enemyof Good
  • 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. © 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. © 2011 VersionOne 10How might we avoid taking on too muchdebt?
  • 11. © 2011 VersionOne 11Test Driven Development
  • 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. © 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. © 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. © 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. © 2011 VersionOne 16Don’t take on more than you can pay
  • 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. © 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. © 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. © 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. © 2011 VersionOne 21Alternative ways to consider debt• Choose a metaphor that resonates• Not everyone is comfortable with the money theme
  • 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. © 2011 VersionOne 23Some basic tips
  • 24. © 2011 VersionOne 24Recognize your debt• Don’t sweep it under the rug• “It goes without saying” doesn’t
  • 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. © 2011 VersionOne 26Track debt• Note the “interest rate”• Calculate the costs at periodic intervals
  • 27. © 2011 VersionOne 27Plan to pay your debt, just like you plan fornew features
  • 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. © 2011 VersionOne 29Remember, you can pay me now, or you canpay me later…