Controlling Complexity, Eliminating Technical Debt, & Chimera Pet-Care

1. /
Controlling Complexity,
Eliminating Technical Debt, &
Chimera Pet-Care
Illusions of Engineering
Wednesday, September 16, 2009

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

3. Technical Debt Misunderstood
Interest on technical debt
is time spent on
“not-quite-right”
code.
Wednesday, September 16, 2009

4. Technical Debt Misunderstood
I find that many developers
poorly define
“not-quite-right”
Wednesday, September 16, 2009

5. Technical Debt: Developer’s Perspective
Lack of elegance.
Lack of extensibility.
Wednesday, September 16, 2009

6. Technical Debt: Engineer’s Perspective
does not meet:
functional specifications;
security requirements;
performance requirements.
Wednesday, September 16, 2009

7. Technical Debt Misunderstood
Why?
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

14. Typical technical debt
Lack of documentation.
Lack of optimization.
Wednesday, September 16, 2009

15. Risky technical debt
Lack of complete function.
Lack of complete tests.
Lack of architectural design.
Wednesday, September 16, 2009

16. Reality
80% of elegance is useful,
20% is self-indulgence.
We call this part “good engineering.”
Wednesday, September 16, 2009

17. Reality
You likely have no idea how
someone (even you)
will want to extend your code.
Wednesday, September 16, 2009

18. Reality
100% of premature
optimization is wasteful.
Not all optimization is
premature.
Good luck.
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

21. RULE II
Observe the
Principle of Least Surprise
Wednesday, September 16, 2009

22. RULE III
Keep
It
Simple,
Stupid
Wednesday, September 16, 2009

23. RULE IV
If your code isn’t elegant
it’s worth less.
If your code doesn’t work
it’s worthless.
Wednesday, September 16, 2009

24. RULE V
Write functional tests.
Wednesday, September 16, 2009

25. RULE VI
Always use best coding
practices.
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