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 debtis time spent on

“not-quite-right”code.



I find that many developerspoorly 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 projecton the original budget.



New functional requirements have new budgets andthe cost of refactoringexisting components

can and mustbe included.



Choosing to not refactorwhen needed converts

technical debt intofinancial 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 tofunction or securityshall not be used.

Instead tryfunction or security.


RULE II

Observe thePrinciple of Least Surprise


RULE III

Keep

It

Simple,

Stupid


RULE IV

If your code isn’t elegantit’s worth less.

If your code doesn’t workit’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” issoftware 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 abetter engineer

and align your goalswith those of the project.


project reality

Software