A metaphor to raise awareness: a debt requires interest payment (extra development effort). 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 a debt – Cunningham (1992).
Technical Debt shortcuts purposely taken Bad things that plague systems Bad design Defects Insufficient test coverage Excessive manual testing Poor integration management Lack of platform experience
Technical Debt shortcuts purposely taken Bad things that plague systems Bad design Defects Insufficient test coverage Excessive manual testing Poor integration management Lack of platform experience
Technical Debt shortcuts purposely taken Bad things that plague systems Bad design Defects Insufficient test coverage Excessive manual testing Poor integration management Lack of platform experience • Naïve Debt • Unavoidable Debt • Strategic Debt
Debt § Not originally intended to be referred as technical debt (Cunningham). Reckless debt (Fowler 2009). Unintentional debt (McConnell 2007). Just mess (Martin 2008) § Origin: team members or business immaturity or process deficiencies that lead to sloppy design, poor engineering practices, and a lack of testing. § Solution: Proper training. Good understanding of technical practices.
Debt § Debt can be a tool that can be used to better quantify and leverage the economics of important time-sensitive decisions. § Shortcuts during product development to achieve a short-term goal. § It is a tool, but as any debt, it should be repaid.
to do? § Continue paying the interest (by working around the problems), or § pay down the debt principal (for example, refactoring the code). § As the level of debt rises, so does the severity of the consequences.
§ Unpredictable tipping point. Debt grows in an unpredictable nonlinear fashion. At the tipping point, even small changes become major occasions of uncertainty. § Increased time to delivery. The greater the debt today, the slower the velocity tomorrow. § Defects. Debt increase complexity therefore it is harder to do things correctly. § Rising Cost of Change. Built + Repair
§ Product Atrophy. Product ceases to be a viable option. § Decreased predictability. Any prediction is nearly impossible. Estimates become bad estimates even for the most experienced team members. § Underperformance (teamwork). Increment of technical debt lower development performance and therefore reduce expectations of what is possible. § Frustration. People burn out.
§ Debt builds on Debt. § Do nothing, and the problem gets worse. § Make ever-larger investments in technical debt reduction and consume more and more development resources. § Manage technical debt before it spirals out of control, i.e., technical bankruptcy.
accrual No product is debt free. So how much technical debt we can take on? Product Owner should help to balance business and technical perspectives to make trade-offs What to do? § Stop adding naïve debt (TDD, automating testing, continuous integration, refactoring, etc). § Understand technical debt economics.
Technical debt What to do? • Not all technical debt should be repaid products with a short life or prototypes. • Boy scout rule “leave the campground cleaner than you found it”. • Happened-upon technical debt. Clean up until you reach a predefined threshold. And, classify the rest adding entries to the product backlog (Known technical debt). Each sprint use some resources (time) to pay selected (targeted technical debt).
javiergs
bkuhlmann
lovee
layzee
itok
alperhankendi
mehowte
mihyaeru21
ryosukes
grapecity_dev
neripark
jensimmons
addyosmani
trallard
davidbonilla
destraynor
lara
sferik
iamctodd
lynnandtonic
jmmastey
kneath
tanoku
