About Fadi Stephan • 15+ years of experience in software development • Focused on Agile since 2006 • Consultant with Excella • Founder of the DC Software Craftsmanship User Group • Organizer of the DC Scrum User Group
Technical Debt“Shipping first time code is like goinginto debt. A little debt speedsdevelopment so long as it is paid backpromptly with a rewrite... The dangeroccurs when the debt is not repaid.Every minute spent on not-quite-rightcode counts as interest on that debt.” - Ward Cunningham
Technical Debt Metaphor“Neglecting the design is like borrowing money”“Developing slower because of this debt is like payinginterest on the loan”“Refactoring, its like paying off the principal debt”“Every minute spent on not-quite-right code counts asinterest on that debt”
Quick and dirty design results in Principal Interest Technical Debt
Which one will you choose? 1. Quick and Dirty 2. Clean
Managing Technical DebtGiven the option between a clean or dirty approach, which one will you choose?1. Team, this past sprint our velocity was down due to a lot of time spent on UIissues. Let’s not worry about compatibility with other browsers and just writeenough code to make the application work in IE 8. Don’t worry if the code breaksthings on the other browsers. Our corporate policy is for us to support IE 8 only.2. Team, we are behind schedule. We need to catch up quickly. Let’s skip unittesting for now and just get the code working. We’ll come back and write the testsafter we release. The business is counting on us!3. I think it now makes more sense to have the EMAIL field is the EMPLOYEE tableinstead of the ATTRIBUTE table. We don’t have time to change the code, but wecan create a trigger for now to keep the two database tables in sync and we’llrefactor the code after we release.4. This story has a bunch of rules that need to be validated in the business layer. Itwill probably take 40 hours to do. However, I can write the same logic in the UIlayer a lot quicker. I think I can wrap this up in about 8 hours. I’ll be able to movethe code to the business layer in a future sprint when I have more time.
Case 1Team, this past sprint our velocity was down dueto a lot of time spent on UI issues. Let’s notworry about compatibility with other browsersand just write enough code to make theapplication work in IE 8. Don’t worry if the codebreaks things on the other browsers. Ourcorporate policy is for us to support IE 8 only.
Case 2Team, we are behind schedule. We need tocatch up quickly. Let’s skip unit testing for nowand just get the code working. We’ll come backand write the tests after we release. Thebusiness is counting on us!
Case 3I think it now makes more sense to have theEMAIL field is the EMPLOYEE table instead of theATTRIBUTE table. We don’t have time to changethe code, but we can create a trigger for now tokeep the two database tables in sync and we’llrefactor the code after we release.
Case 4This story has a bunch of rules that need to bevalidated in the business layer. It will probablytake 40 hours to do. However, I can write thesame logic in the UI layer a lot quicker. I think Ican wrap this up in about 8 hours. I’ll be able tomove the code to the business layer in a futuresprint when I have more time.
Types of Debt• Unintentional• Intentional – Short term & focused – Short term & unfocused – Long term• Only short term focused debt & long term debt are “good” debt forums.construx.com/blogs/stevemcc/archive/2007/11/01/technical-debt-2.aspx
Approach• Have a technical debt reduction sprint immediately after a release• Have a technical debt reduction sprint once we reach a certain limit• Rotate dedicated members to work on reducing technical debt• Dedicate 10% of each sprint to reducing technical debt• Reduce technical debt by story
SummaryManaging technical debt requires that we makeprudent and deliberate decision ondesign & quality
SummaryProvide transparency by 1. Registering any new debt 2. Assessing existing debt
SummaryInspect by 1. Monetizing the debt 2. Establishing a debt limit 3. Monitor trends
SummaryAdapt by 1. Paying down the debt focusing on high interest rate 1st. 2. Starting with what you know. Train for the rest 3. Continuously monitor the debt
AcknowledgementRobert Martin Steve McConnell Israel Gat Martin Fowler
References• Design Principles and Design Patterns - Robert Martin• Design Stamina Hypothesis - martinfowler.com/bliki/DesignStaminaHypothesis.html• Technical Debt Quadrant - martinfowler.com/bliki/TechnicalDebtQuadrant.html• The Agile Triangle – theagileexecutive.com/tag/the-agile-triangle/• Technical Debt Assessment and Reduction – theagileexecutive.com/category/technical-debt/• Technical Debt, Cutter IT Journal October 2010 - www.cutter.com
References• Technical Debt A Perspective for Manager – www.infoq.com/articles/technical-debt-levison• Managing Technical Debt - blogs.versionone.com/agile_management/2011/07/11/managing-technical-debt/• What Testers Can Do About Technical Debt - www.stickyminds.com/sitewide.asp?ObjectId=3629• Climb Out of Technical Debt – www.ayeconference.com/climboutoftechnicaldebt/• Dont Live with Broken Windows – www.artima.com/intv/fixit.html
References• Technical Debt - forums.construx.com/blogs/stevemcc/archive/2007/11/01/technical-debt- 2.aspx• Sonar – http://www.sonarsource.org/evaluate-your-technical-debt-with-sonar/• Pay Down your Technical Debt – www.codinghorror.com/blog/2009/02/paying-down-your-technical-debt.html• SQALE Method For Evaluating Technical Debt – http://www.sqale.org/wp-content/uploads/2012/04/SQALE-3RD-WS-on-MTD.pdf