Project reality

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

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

Technical Debt Misunderstood
Interest on technical debt
is time spent on
“not-quite-right”
code.

I find that many developers
poorly define
“not-quite-right”

Technical Debt: Developer’s Perspective
Lack of elegance.
Lack of extensibility.

Technical Debt: Engineer’s Perspective
does not meet:
functional specifications;
security requirements;
performance requirements.

Why?

Technical Debt Understood
Fixing function, security or
performance issues is part of
the original project
on the original budget.

New functional requirements
have new budgets and
the cost of refactoring
existing components
can and must
be included.

Choosing to not refactor
when needed converts
technical debt into
financial debt.

Technical debt as a tool
Debt is a financial instrument;
Technical debt is a software
engineering instrument.

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.

Safe technical debt
Lack of elegance.
Lack of extensibility.
Rapid prototyping. END.

Typical technical debt
Lack of documentation.
Lack of optimization.

Risky technical debt
Lack of complete function.
Lack of complete tests.
Lack of architectural design.

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

Reality
You likely have no idea how
someone (even you)
will want to extend your code.

Reality
100% of premature
optimization is wasteful.
Not all optimization is
premature.
Good luck.

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)

RULE I
TODOs related to
function or security
shall not be used.
Instead try
function or security.

RULE II
Observe the
Principle of Least Surprise

RULE III
Keep
It
Simple,
Stupid

RULE IV
If your code isn’t elegant
it’s worth less.
If your code doesn’t work
it’s worthless.

RULE V
Write functional tests.

RULE VI
Always use best coding
practices.

RULE VII
Optimize everything*
* consider the optimal approach to each problem and articulately
justify using anything else in comments/documentation

The Truth
The “Truth” is
software engineering
is a hard balance

The Truth
Technical debt must be
measured along side:
financial budgets,
time budgets,
opportunity costs,
expected project longevity.

Parting thought
I challenge you to be a
better engineer
and align your goals
with those of the project.

Project reality

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (20)

Similar to Project reality

Similar to Project reality (20)

More from Theo Schlossnagle

More from Theo Schlossnagle (11)

Recently uploaded

Recently uploaded (20)

Project reality