The document discusses the concept of technical debt, which refers to shortcuts taken in software development that incur additional costs down the road. It defines technical debt as work that will cost more to do later than it would cost to do properly now. While taking on some technical debt can speed up development in the short term, it accrues interest over time as more work is needed to maintain the low-quality code. The document examines reasons for and perspectives on technical debt from both business and technical viewpoints, and discusses ways to track, measure, and strategize around managing technical debt.

1. (Managing) Technical
Debt (Steve McConnell)
Gustavo Muñoz
VP & CTO, Grupo Expansión (A Time Inc. Company)
July 4, 2013
Thursday, July 4, 13

2. 1992, Ward Cunningham
“Another, more serious pitfall is the failure to consolidate.
Although immature code may work fine and be completely
acceptable to the customer, excess quantities will make a
program unmasterable, leading to extreme specialization of
programmers and finally an inflexible product.
Thursday, July 4, 13

3. 1992, Ward Cunningham
Shipping first time code is like going into debt. A little debt
speeds development so long as it is paid back promptly with
a rewrite. Objects make the cost of this transaction tolerable.
The danger occurs when the debt is not repaid. Every minute
spent on not-quite-right code counts as interest on that debt.
Entire engineering organizations can be brought to a stand-
still under the debt load of an unconsolidated
implementation, object-oriented or otherwise”.
Thursday, July 4, 13

4. 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 (including increased cost over time)"
—Steve McConnell
Thursday, July 4, 13

5. Technical Debt
The term technical debt is defined as the cost to improve
technical quality up to a level that is considered ideal.
The interest of technical debt is the extra cost spent on
maintaining software as a result of poor technical quality.
Technical debt grows over time if not resolvedbecause the
quality of changes performed on top of systems of poor
technical quality tend to be poor.
Thursday, July 4, 13

6. Maintenance vs Tech Debt
Maintenance encompasses activities such as adding new
functionality and fixing bugs.
Maintenance is different from technical quality repair in that
it involves visible changes and their impacts are immediately
visible (e.g., fixing bugs or adding new features).
Extra effort spent on retrofitting new functionality or fixing
bugs are examples of interest on technical debt.
Thursday, July 4, 13

7. 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”.
Thursday, July 4, 13

8. 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.”
Thursday, July 4, 13

9. Why 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.
Thursday, July 4, 13

10. Why Discuss Technical Debt
Allows technical debt to be managed more explicitly.
The analogy is rich and produces numerous insights
Thursday, July 4, 13

11. A tiny video (4:44)
http://www.youtube.com/watch?v=pqeJFYwnkjE
Thursday, July 4, 13

12. Reasons to Take on Technical Debt
The Business View
Shortening time to market
Preserving startup capital
Delaying development expense
Business staff tend to be optimistic (or ignorant) about the
benefit of taking on the debt and about the costs of carrying
the debt
Thursday, July 4, 13

13. Reasons to Take on Technical Debt
The Technical View
Debt can create a vicious circle
Thursday, July 4, 13

14. Reasons to Take on Technical Debt
The Technical View
Technical staff tends to be pessimistic about the benefit of
taking on the debt and about the costs of carrying the debt
Attitude toward debt can be religious
Attitude toward debt can be aesthetic
Thursday, July 4, 13

15. Business vs. Technical Viewpoints
Business staff tends to be optimistic about debt
Technical staff tends to be pessimistic about debt
These attitudes are often not conscious
Debt is a tool, neither inherently good nor bad
The Technical Debt metaphor gives these two groups a
constructive way to approach some important discussions
Thursday, July 4, 13

16. 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”
Decreasing velocity can be an indicator
Thursday, July 4, 13

17. How Much Debt is Enough/Too Much?
Business staff tends to have a higher tolerance for technical
debt (but weaker memory of it)
Work is required to ensure the organization remembers its
debt decisions
Thursday, July 4, 13

18. Technical Debt Landscape
Thursday, July 4, 13

19. Tracking Debt
All “good debt” can be tracked (by definition)
Log as defects
Include in product backlogs
Monitor project velocity
Monitor amount of rework
Thursday, July 4, 13

20. Things to do (whole story)
Green: new features
Red: defects
Yellow: arch elements
Black: technical debt
Thursday, July 4, 13

21. Ways to measure Debt
Total of debt in product backlog
Maintenance budget (or fraction of maintenance budget)
“Aged” customer work backlog
Measure debt in money, not features, e.g., “50% of R&D
budget is nonproductive maintenance work”
Thursday, July 4, 13

22. What can we do with TD
Thursday, July 4, 13

23. “Reification”
The main value of “technical debt” is reifying a concept
that’s otherwise too intangible to be handled well
Thursday, July 4, 13

24. What can we do about it?
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
Thursday, July 4, 13

25. What can we do about 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
Thursday, July 4, 13

26. Thanks...
and sorry!
Thursday, July 4, 13