Technical Debt has become a catch-all phrase for any code that needs to be re-worked. Much like Refactoring has become a catch-all phrase for any activity that involves changing code. These fundamental misunderstandings and comfortable yet mis-applied metaphors have resulted in a plethora of poor decisions. What is technical debt? What is not technical debt? Why should we care? What is the cost of misunderstanding? What do we do about it? Doc discusses the origins of the metaphor, what it means today, and how we properly identify and manage technical debt.
5. Shipping first time code is like going into debt.
OOPSLA ‘92
Ward Cunningham
6. 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.
OOPSLA ‘92
Ward Cunningham
7. The danger occurs when the debt is not repaid.
Every minute spent on not-quite-right code
counts as interest on that debt.
OOPSLA ‘92
Ward Cunningham
8. The danger occurs when the debt is not repaid.
Every minute spent on not-quite-right code
counts as interest on that debt.
OOPSLA ‘92
Ward Cunningham
14. Metaphor’s Rock
We Reason by Analogy
Building on
a weak
foundation
Puts pressure on
our design
Can’t keep running
at this pace
It’s raining men
(hallelujah)
15. Metaphorphosis
When Metaphors Go Wrong
SHORT-TERM
Long-Term
INADVERTENT RECKLESS
DEBT IN THE THIRD
QUADRANTPrudent
Intentional
Credit Card
FRAUDULENT
AUTO LOAN
Student Loan
HOME LOAN
Loan Shark
Return on Investment
PYRAMID SCHEME
VOLUNTARY
PRAGMATIC LEVERAGE
HIGH INTEREST
OPERATIONAL
16. Metaphorphosis
When Metaphors Go Wrong
“QUICK AND DIRTY”
MARTIN FOWLER
HTTP://WWW.MARTINFOWLER.COM/BLIKI/TECHNICALDEBT.HTML
“SLOPPY”
DAVID LARIBEE
HTTP://MSDN.MICROSOFT.COM/EN-US/MAGAZINE/EE819135.ASPX
“JUST HACK IT IN”
STEVE MCCONNELL
HTTP://BLOGS.CONSTRUX.COM/BLOGS/STEVEMCC/ARCHIVE/2007/11/01/TECHNICAL-DEBT-2.ASPX
“CUT A LOT OF CORNERS”
JAMES SHORE
HTTP://JAMESSHORE.COM/BLOG/CARDMEETING/VOLUNTARY-TECHNICAL-DEBT.HTML
17. The Technical Debt Quadrant
http://martinfowler.com/bliki/TechnicalDebtQuadrant.html
18. [Many] have explained the debt metaphor and
confused it with the idea that you could write code
poorly with the intention of doing a good job later.
YouTube ‘09
Ummm… No.
http://www.youtube.com/watch?v=pqeJFYwnkjE&feature=player_embedded
20. The ability to pay back debt [...] depends upon
you writing code that is clean enough to be able to
refactor as you come to understand your problem.
YouTube ‘09
Clean Code is
Required
http://www.youtube.com/watch?v=pqeJFYwnkjE&feature=player_embedded
21. The ability to pay back debt [...] depends upon
you writing code that is clean enough to be able to
refactor as you come to understand your problem.
YouTube ‘09
Clean Code is
Required
http://www.youtube.com/watch?v=pqeJFYwnkjE&feature=player_embedded
22. Twitter ‘09
Dirty Code is a Bad
Idea
Dirty code is to technical debt as the pawn
broker is to financial debt.!
http://twitter.com/WardCunningham/status/3742903303
Don’t think you are ever going to get your
code back.
23. Is it Technical Debt?
Ask yourself…
❖ Is the code clean?!
❖ Is the code tested?!
❖ Is there a learning objective or event?!
❖ Is there a plan for payback?!
❖ Is the business truly informed?
24. Is it Technical Debt?
If you say no to even one…
❖ Is the code clean?!
❖ Is the code tested?!
❖ Is there a learning objective or event?!
❖ Is there a plan for payback?!
❖ Is the business truly informed?
... then you don’t have Technical Debt
25. You have a mess
Mess (noun)
❖ Disorderly accumulation, heap, or jumble!
❖ A state of embarrassing confusion!
❖ An unpleasant or difficult situation
26. You have cruft
Cruft (noun)
❖ An unpleasant substance!
❖ The result of shoddy construction!
❖ Redundant, old or improperly written code
27. Chill. It’s just semantics, man.
Just Semantics?
Technical Debt is Good
28. Chill. It’s just semantics, man.
Just Semantics?
Technical Debt is GoodQuick and Dirty is Technical DebtQuick and Dirty is Good
29. Chill. It’s just semantics, man.
Just Semantics?
Quick and Dirty is GoodQuick and Dirty is Good
30. The Technical Debt Quadrant
http://martinfowler.com/bliki/TechnicalDebtQuadrant.html
31. The Technical Debt Quadrant
http://martinfowler.com/bliki/TechnicalDebtQuadrant.html
“Let’s deploy and
gather more
information.”
44. Cruft or Debt?
double getSpeed() {!
switch (_type) {!
case EUROPEAN:!
return getBaseSpeed();!
case AFRICAN:!
return getBaseSpeed() - getLoadFactor() * _numberOfCoconuts;!
case NORWEGIAN_BLUE:!
return (_isNailed) ? 0 : getBaseSpeed(_voltage);!
}!
throw new RuntimeException ("Should be unreachable");!
}!
http://www.refactoring.com/catalog/replaceConditionalWithPolymorphism.html
45. Cruft or Debt?
class Swallow ...!
double getSpeed() { return getBaseSpeed(); }!
end class!
!
class EuropeanSwallow ...!
end class!
!
class AfricanSwallow ...!
double getSpeed() { return super.getSpeed - coconutLoad(); }!
double coconutLoad() { return getLoadFactor() * _numberOfCoconuts; }!
end class!
!
class NorwegianSwallow ...!
double getSpeed() { return (_isNailed) ? 0 : getBaseSpeed(_voltage); }!
end class
46. Cruft is a bad decision
Every Time
❖ You are a professional developer!
❖ You’re going to create unintentional cruft!
❖ You have to clean up the existing cruft
47. The Trap
Cruft begets Cruft
❖ Precedent for speed over quality!
❖ Expectation of increased velocity!
❖ Cruft slows you down!
❖ Must write more cruft to keep up!
❖ Ask permission to do your job correctly
48. Avoid The Trap
Thresholds set false expectations
http://blog.castsoftware.com/wp-content/uploads/2011/04/Technical-Debt-Software-Quality1.jpg
49. Avoid The Trap
Incremental fixes fail
http://www.jacoozi.com/blog/wp-content/uploads/2007/01/refactoring_coc_big.jpg
51. Avoid The Trap
Clean Constantly
❖ Never make an intentional mess!
❖ Monitor your “Technical Debt”!
❖ Follow the Boy Scout Rule!
❖ Remember quality is your responsibility!
❖ NEVER ask permission to do your job correctly
53. Monitoring Cruft/Debt
Code Coverage
❖ Code exercised by automated tests!
❖ Monitor types of tests separately!
❖ Don’t set a coverage target!
❖ 100% coverage is a smell!
❖ Monitor Trends, Not Points
54. Monitoring Cruft/Debt
Complexity
❖ Count of logical branches in code!
❖ Direct relationship with bugs!
❖ Typically high in concentrated areas!
❖ Reduce conditionals!
❖ Monitor Trends, Not Points
57. Review
Technical Debt
❖ A strategic design decision!
❖ Requires business to be informed!
❖ Includes a pay-back plan
Cruft
❖ Happens!
❖ Needs to be monitored and cleaned!
❖ Is NOT Technical Debt
58. Review
Technical Debt
❖ A strategic design decision!
❖ Requires business to be informed!
❖ Includes a pay-back plan
Cruft
❖ Happens!
❖ Needs to be monitored and cleaned!
❖ Is NOT Technical Debt
NEVER
ask
perm
ission
to do your job
correctly