Managing Technical Debt
- 2. Copyright Notice These class materials are © 2007-2011 by Steven C. McConnell and Construx Software Builders, Inc. All Rights Reserved. No part of the contents of this seminar may be reproduced or transmitted in any form or by any means without the written permission of Construx Software Builders, Inc.
- 3. Technical Debt A design or construction approach that's expedient in the short term but that creates a technical context in which the same work will cost more to do later than it would cost to do now 3
- 4. Technical Debt Example “Guys, we don‟t have time to dot every I and cross every t on this release. Just get the code done. It doesn‟t have to be perfect. We‟ll fix it after we release.” 4
- 5. Technical Debt Example “We don't have time to reconcile these two databases before our deadline, so we'll write some glue code that keeps them synchronized for now and reconcile them after we ship.” 5
- 6. Reasons to Discuss Technical Debt Helps to educate technical staff about business decision making Helps to educate business staff about technical decision making Raises awareness/transparency of important issues that are often buried Allows technical debt to be managed more explicitly The analogy is quite rich and produces numerous insightful parallels 6
- 7. Objectives of this Talk Introduce the technical debt concept Show the full scope of what‟s possible with the concept (i.e., this talk is just the tip of the iceberg) 7
- 8. Talk Roadmap A Debt Primer A Technical Debt Quiz Ins and Outs of the Technical Debt Analogy Deciding to Take on Technical Debt Tracking Technical Debt Paying Down Technical Debt Summary: What Can we Do with Technical Debt? 8
- 10. The Business View Reasons to Take on Technical Debt Shortening time to market Preserving startup capital Delaying development expense 10
- 11. The Technical View Reasons Not to Take on Technical Debt Debt can create a vicious circle 11
- 12. Business vs. Technical Viewpoints Business staff tend to be optimistic about the benefit of taking on the debt and the costs of carrying the debt Technical staff tends to be pessimistic about the benefit of taking on the debt and the costs of carrying the debt The truth is normally somewhere in the middle The Technical Debt metaphor gives these two groups a constructive way to approach some important discussions 12
- 13. Short-Term vs. Long-Term Debt Short-Term Debt Financial Debt Used to finance temporary cash flow issues, e.g., to cover receivables Expectation is normally that debt will be repaid in the short term Technical Debt Skipping unit tests to get a release out the door "We don't have time to implement this the right way; just hack it in and we'll fix it after we ship." Violating coding standards to upload a hot fix 13
- 14. Short-Term vs. Long-Term Debt Long-Term Debt Financial Debt Used to finance longer term investments Expectation is normally that there is some strategic reason for taking on long-term debt Technical Debt “We don‟t think we‟re going to need to support a second platform for at least 5 years, so our design supports only one platform.” 14
- 15. Intentional vs. Unintentional Debt Intentional Debt “If we don‟t get this release done, there won‟t be a second release.” (Rationale for cutting corners) “We have code written by a contractor that doesn‟t follow our coding standards. We‟ll clean that up later.” “We didn‟t have time to write unit tests for all the code we wrote the last 2 months of the project. We‟ll write those after we release.” 15
- 16. Intentional vs. Unintentional Debt Unintentional Debt A junior programmer writes bad code A major design strategy turns out poorly Your company acquires a company that has a lot of technical debt A comprehensive refactoring project goes sideways 16
- 17. More Examples of Technical Debt Code level Design level Violations of coding standards No coherent design Code duplication (“parallel Inconsistent design mods”) approaches “Style drift” (coding standards Code-level violations of that change over time in a design standards long-lived code base leading Poor choice of components, to inconsistent coding style) frameworks, etc. “Style clash” (code bases Design choices that turn out developed separately that are to be wrong in hindsight (“If brought together over time, only we‟d known then…”) leading to inconsistent style) Testing level Poor or absent comments Brittle test suites Poor or absent unit tests Incomplete test coverage Generally sloppiness Etc. 17
- 18. Interest / Debt Service Interest is a premium paid above and beyond the principal that is in essence a service charge for being allowed to take on the debt Interest can be paid periodically or all at once when the debt is repaid To qualify as “debt,” there must be some kind of interest—now or later or both 18
- 19. Examples of “Interest Payments” on Technical Debt Lack of unit tests on legacy code causes new development, testing, and debugging to take longer Overly simple design does not readily support changes in the environment, and seemingly simple environment changes require massive code rework High product support cost for a buggy system Brittle system means each bug fix introduces unintended side effects (i.e., new bugs), so each simple bug fix becomes a multi- bug-fix project Bug reports are so frequent that time spent fixing bugs in the production system prevents any work on new functionality Overly lengthy edit-compile-debug times due to poor development environment 19
- 20. Consider the Debt’s Interest Rate Not all debt is equal Pay off high interest debt before you pay off low interest debt Some low interest debt may be low enough that you never pay it off (moral equivalent of a home mortgage at 4.5%) Pay Off Debt? Yes Debt Impact (Interest Maybe Payment) No Debt Pay-Off Cost 20
- 21. Technical Debt Quiz: Good or Bad Debt?
- 22. Good or Bad Debt? “We don't have time to reconcile these two databases before our deadline, so we'll write some glue code that keeps them synchronized for now and reconcile them after we ship.” 22
- 23. Good or Bad Debt? “Guys, we don‟t have time to dot every I and cross every t on this release. Just get the code done. It doesn‟t have to be perfect. We‟ll fix it after we release.” 23
- 24. Good or Bad Debt? “There is a right way and a wrong way to fully support the next version of Android. The „right‟ way will cost us 100 staff months now. The „wrong‟ way will cost us 10 staff months now plus 2 staff months in added production support for every month the system is in production. Since we‟re planning to completely replace the system in 18 months, lifetime cost of the „wrong‟ way is 46 staff months, which is cheaper and quicker than the 100 month approach. So the „wrong‟ way is the better option.” 24
- 25. Good or Bad Debt? “Our old system was crumbling, so we took on a 6-month refactoring / rearchitecture project. After 6 months of work we weren‟t able to converge a release so we had to back out a lot of the work we had done. The system we have now is a Frankenstein‟s Monster that is buggier than the old system we were trying to replace.” 25
- 26. Summary of Categories of Technical Debt Unintentional Debt. Debt incurred unintentionally due to low quality work. Honest Mistakes. “I wish we‟d known Framework 2.1 would be so much better than Framework 2.0.” Careless Mistakes. “Design? What design? Design is for sissies.” Intentional Debt. Debt incurred intentionally Short-Term Debt. Short-term debt, usually incurred reactively, for tactical reasons Focused Short-Term Debt. Individually identifiable shortcuts (like a car loan, e.g., partial implementation of a class) Unfocused Short-Term Debt. Numerous tiny shortcuts (like credit card debt, e.g., not following the coding standard) Long-Term Debt. Long-term debt, usually incurred proactively, for strategic reasons 26
- 27. Summary of Categories of Technical Debt Unintentional Debt. Debt incurred unintentionally due to low quality work. Honest Mistakes. “I wish we‟d known Framework 2.1 would be so much better than Framework 2.0.” Careless Mistakes. “Design? What design? Design is for sissies.” Intentional Debt. Debt incurred intentionally Short-Term Debt. Short-term debt, usually incurred reactively, for tactical reasons Focused Short-Term Debt. Individually identifiable shortcuts (like a car loan, e.g., partial implementation of a class) Unfocused Short-Term Debt. Numerous tiny shortcuts (like credit card debt, e.g., not following the coding standard) Long-Term Debt. Long-term debt, usually incurred proactively, for strategic reasons 27
- 28. Interest and Interest Payments Is This Technical Debt? "We don't think we're going to need to support a second platform for at least three years, so this release can be built on the assumption that we're supporting only one platform. If we need to support a second platform we will do that work later." 28
- 29. Interest and Debt Service Not All Delayed Work is Debt Many kinds of delayed or incomplete work are not debt: feature backlog, deferred features, cut features If the work doesn‟t create an interest payment of some kind, it isn‟t debt 29
- 30. Ins and Outs of the Technical Debt Analogy
- 31. Credit Rating Different consumers/businesses have different borrowing power based on their credit rating Teams have different abilities to carry technical debt responsibly A team with a lot of unintentional debt due to low quality work will have less ability to take on debt for strategic reasons than a team with lower unintentional debt 31
- 32. Acquired Debt Debt was taken on for important strategic reasons, but you weren‟t there at the time Debt was taken on for reasons that you (or your team) would never have bought into if you had been there at the time Sometimes you acquire debt from another company in an acquisition 32
- 33. 90 Days Same as Cash! Sometimes this option is available, i.e., no interest accrues if you pay the debt off quickly enough 33
- 34. Low Monthly Payments! When debt is incurred, what threshold level of activity is needed to make the “minimum payment?” Roll up a new version on a website? Send out DVDs? Replace a chip in a computer? Replace a box on an airplane? Ability to pay off debt depends in part on the kind of software the debt applies to 34
- 35. Retiring Debt Teams normally find “working off debt” to be motivating Special Case: End of Life System Unlike financial debt, when a system is retired, all its technical debt is retired with it As a system approaches end of life, cost justifying anything other than the most expedient solution becomes increasingly difficult 35
- 36. Deciding to Take On Technical Debt
- 37. Debt Decision Making Option 1 Immediate cost of Good Solution: 10 staff days Deferred cost to retrofit Good Solution: 0 staff days Option 1 cost now: $6,000* Option 1 cost later: $0 Option 1 total cost: $6,000 * Assuming cost of $600/staff day 37
- 38. Debt Decision Making Option 2 Immediate cost of Quick & Dirty solution with possible interest payment: 2 staff days Deferred cost to retrofit Good Solution: 12 staff days Estimated cost of "interest payments": 1-3 staff days Option 2 cost now: $1,200 Option 2 cost later: $7,800-$9,000 Option 2 total cost: $9,000-$10,200 38
- 39. Debt Decision Making Option 3 Immediate cost of Quick & Dirty solution with no interest payment: 3 staff days Deferred cost to retrofit Good Solution: 12 staff days Option 3 cost now: $1,800 Option 3 cost later: $7,200 Option 3 total cost: $9,000 39
- 40. Debt Decision Making Option 3 Immediate cost of Quick & Dirty solution with no interest payment: 3 staff days Deferred cost to retrofit Good Solution: 12 staff days Option 3 cost now: $1,800 This may be the only cost we ever have to Option 3 cost later: $7,200 care about Option 3 total cost: $9,000 40
- 41. Key Point in Taking on Debt Avoid binary “debt/no debt” decisions—the universe of options is rarely that limited Especially look for “zero interest” options Give yourself the option of never paying off the debt 41
- 42. Key Questions to Ask Before Deciding to Take on Debt Do we have estimates for the debt and non- debt options? Do we believe the estimates? How much do we reduce our effort now by taking on the specific technical debt? How much will the quick & dirty option cost now? How much will the “clean” option cost now? How much will it cost later to replace the Q&D option with the clean option? 42
- 43. Key Questions to Ask Before Deciding to Take on Debt How much will the “interest payment” on the Q&D option be? How will the interest payment be structured, i.e., when will we have to pay “interest”? Are there any issues involved in paying back the debt? Why do we believe that it is better to incur the effort later than to incur it now? What is expected to change that will make the payment more palatable in the future than it is now? Can we track this specific debt? Have we considered all options—especially have we considered any zero interest options that we can implement at low cost now? Who in the business is going to own the debt? 43
- 44. How Much Debt is Enough/Too Much? There is no one right answer for business debt, and there is no one right answer for technical debt Technical staff‟s attitude is sometimes extreme: “zero debt” Business staff tends to have a higher tolerance for technical debt (but shorter memory) Work is required to ensure the organization remembers its debt decisions 44
- 45. Indicators of Undesirable Debt High interest rate High minimum payment Required, ongoing payments Debt is untrackable Debt is not intentional Low ROI 45
- 47. Tracking Debt All “good debt” can be tracked (by definition) Log as defects Include in product backlogs Monitor project velocity Monitor amount of rework 47
- 48. Ways to Measure Debt Total of debt in product backlog Maintenance budget (or fraction of maintenance budget) “Aged” customer work backlog Considering measuring debt in money, not features, e.g., “50% of R&D budget is non- productive maintenance work” 48
- 50. Good and Bad Reasons to Pay Down Debt Good reasons are normally based on business need/business benefit Bad reasons (aka, reasons that business people won‟t accept) tend to be very technical sounding 50
- 51. Example of a Good Reason to Pay Down Debt Scenario: Pay off short-term debt Example: “We took some conscious short cuts to get the last release out the door, and now we need to clean up the code before we start writing new functionality.” 51
- 52. Example of a Good Reason to Pay Down Debt Scenario: Debt service (in the form of longer release cycles) is undermining business operations Example: “We‟ll be able to get future releases out in 5 months instead of 6 if we can spend X amount of time reducing our debt” 52
- 53. Example of a Good Reason to Pay Down Debt Scenario: Debt (in the form of technical limitation) is preventing access to new business opportunities Example: “If we spend X weeks working on technical infrastructure in Area Y, we‟ll be able to add features A, B, and C, which we can‟t add now because of shortcuts we took when we originally implemented Area Y.” 53
- 54. Bad Reasons to Pay Down Technical Debt Business is rarely motivated to pay down technical debt because the design is “bad,” “old,” “crufty,” “not object-oriented,” “not agile,” etc. Justification for reducing debt needs to be tied to business benefit Some debt reduction can be planned into normal work flow as part of doing a good job and doesn‟t have to be justified separately 54
- 55. Approaches to Actually Paying Down Technical Debt Do a debt reduction iteration immediately following full product release (for short-term debt) Amortize small debt payments into each iteration (e.g. 10% of effort each iteration) Above a certain threshold (~250 hours?) debt reduction has to be approved as a separate project Individuals rotate through debt-reduction duty Offshore resources are used to reduce debt 55
- 56. Summary: What Can We Do With Technical Debt?
- 57. What Can We Do With Technical Debt? We can: Talk with technical staff about it Communicate to business staff the implications of it Measure the amount of it Make explicit decisions about whether we should take on more of it Get input from the business about whether the business believes we should have less or more of it Strategize how to avoid it Track it Make explicit decisions about when and how to reduce it 57
- 58. Technical Debt Resources SteveMcC‟s blog: Technical Debt Technical Debt Decision Making Martin Fowler‟s bliki Technical Debt Technical Debt Quadrant C2 Wiki Technical Debt page Second International Workshop on Managing Technical Debt (May 23, 2011, co-located with ICSE 2011) 58
- 59. Construx Software is committed to helping individuals and organizations improve their software development practices. For information about our training and consulting services, contact stevemcc@construx.com. Seminar Schedule: www.construx.com/calendar 10900 NE 8th Street, Suite 1350 Bellevue, WA 98004 +1 (866) 296-6300 www.construx.com
Editor's Notes
- #27: Intentional debtDebt taken on consciously for a specific purpose, like buying a houseUnintentional DebtDebt taken on unconsciously for no particular reason, like too much dining out or unexpected medical billsIn software, the liability a team accumulates by doing a crummy jobRelated to the common, mistaken attempt to trade quality for schedule