2. Technical Debt
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.... 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.
Ward Cunningham:
“
”Wednesday, September 16, 2009
8. Technical Debt Understood
Fixing function, security or
performance issues is part of
the original project
on the original budget.
Wednesday, September 16, 2009
9. Technical Debt Understood
New functional requirements
have new budgets and
the cost of refactoring
existing components
can and must
be included.
Wednesday, September 16, 2009
10. Technical Debt Understood
Choosing to not refactor
when needed converts
technical debt into
financial debt.
Wednesday, September 16, 2009
11. Technical debt as a tool
Debt is a financial instrument;
Technical debt is a software
engineering instrument.
Wednesday, September 16, 2009
12. Technical debt as a tool
If you do not use it,
you will not keep up.
If you do not manage it,
it will suffocate you.
Wednesday, September 16, 2009
13. Safe technical debt
Lack of elegance.
Lack of extensibility.
Rapid prototyping. END.
Wednesday, September 16, 2009
19. Reality
• Implementation averaged 25% over budget [1]
• 52.7% will cost 189% of original estimates [3]
• First year supports costs were underestimated an average of 20% [1]
• 40% failed to achieve their business case within a year of launch [1]
• 75% or more blew their schedules by over 30% [2]
• 31.1% will be canceled before they ever get completed [3]
[1] The Conference Board Survey (2001)
[2] The KPMG Canada Survey (1997)
[3] The Chaos Report (1995)
Wednesday, September 16, 2009
20. RULE I
TODOs related to
function or security
shall not be used.
Instead try
function or security.
Wednesday, September 16, 2009
26. RULE VII
Optimize everything*
* consider the optimal approach to each problem and articulately
justify using anything else in comments/documentation
Wednesday, September 16, 2009
27. The Truth
The “Truth” is
software engineering
is a hard balance
Wednesday, September 16, 2009
28. The Truth
Technical debt must be
measured along side:
financial budgets,
time budgets,
opportunity costs,
expected project longevity.
Wednesday, September 16, 2009
29. Parting thought
I challenge you to be a
better engineer
and align your goals
with those of the project.
Wednesday, September 16, 2009