This document discusses technical debt and provides examples of how it can arise. It defines technical debt as borrowing time against future work by taking shortcuts now. This can occur when requirements change and code needs to be refactored, or when non-core functionality is developed in-house rather than using existing third party tools. The document provides formulas to quantify technical debt and outlines strategies to reduce it such as refactoring, writing less fragile tests, and buying in components rather than recreating functionality.

1. Credit Crunch CodeTechnical DebtBy Woody Pewittwoody@pewitt.org@woodyp

2. AgendaDefining Technical DebtWhy Managing Technical Debt is ImportantQuantifying Technical DebtTechnical Debt Anti-Patterns & FixesFinding Technical Debt Using MetricsSummaryFurther ReadingQuestions.

3. http://www.flickr.com/photos/robandstephanielevy

4. Why should do you care?

5. And who is going to care?

7. Big ball of mud!A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, spaghetti-code jungle.Only those who are unconcerned about architecture, and, perhaps, are comfortable with the inertia of the day-to-day chore of patching the holes in these failing dikes, are content to work on such systems.People who maintain such systems, are often seen wearing socks and sandals.

8. How to you get them?The Big Ball of Mud and Other Architectural Disastershttp://www.codinghorror.comJeff AtwoodOn Brian Foote & Joseph Yoder's Big Ball of Mud paper

9. How to you get them?Shantytown, Spaghetti CodeThrowaway CodePiecemeal GrowthKeep It WorkingShearing LayersSweeping It Under The RugReconstruction

10. Shantytown, Spaghetti Code

11. Throwaway Code

12. Piecemeal Growth

13. Keep It Working

14. Shearing Layers

15. Sweeping It Under The Rug

16. Reconstruction

17. Steve McConnell's36 classic mistakesPeople MistakesUndermined motivationWeak personnelUncontrolled problem employeesHeroicsAdding people to a late projectNoisy, crowded officesFriction between developers and customersUnrealistic expectationsLack of effective project sponsorshipLack of stakeholder buy-inLack of user inputPolitics placed over substanceWishful thinking

18. Steve McConnell's36 classic mistakesProcess MistakesOverly optimistic schedulesInsufficient risk managementContractor failureInsufficient planningAbandonment of planning under pressureWasted time during the fuzzy front endShortchanged upstream activitiesInadequate designShortchanged quality assuranceInsufficient management controlsPremature or too frequent convergenceOmitting necessary tasks from estimatesPlanning to catch up laterCode-like-hell programming

19. Steve McConnell's36 classic mistakesProduct MistakesRequirements gold-platingFeature creepDeveloper gold-platingPush me, pull me negotiationResearch-oriented development

20. Steve McConnell's36 classic mistakesTechnology MistakesSilver-bullet syndromeOverestimated savings from new tools or methodsSwitching tools in the middle of a projectLack of automated source control

21. So What is Technical Debt?

22. Defining TechnicalDebt #1Term coined by Ward Cunningham in 1992Analogous to financial debtFinancial debt = borrow money against a future dateTechnical debt = borrow time against a future date.

23. Defining TechnicalDebt #2With financial debt“Virtual debt” by not having the best interest rateWith Technical DebtNot making savings against time where possible.

24. What is Interest OnTechnical Debt?Cost later – cost nowFinancial value of damage to your brandLoss of market shareLow staff morale

25. Just As Not All FinancialDebt Is Bad

26. Nor Is All Technical Debt

27. But Financial Debt CanBe Dangerous

28. And So CanTechnical Debt

29. Technical Debt QuadrantDeliberate"We must ship now and deal with consequences""We don't have time for design"PrudentReckless"Now we know how we should have done it""What's Layering"Inadvertent

30. Classes of Technical DebtPlanned13KnownUnknown24Unplanned

31. Why Managing Technical Debt is Important?

32. Why Is Managing TechnicalDebt Important?

33. Reduce Effort by Keepingit Under Control

34. Quantifying Technical Debt

35. Basic FormulaTo Get You StartedWhere:T = Total number of employees involved in paying back the debti = The individual employeeHRi = Hourly rate of pay for that individualHi = The hours that an individual worked in paying back the debtEOC = Employer’s on cost – estimated at 40% of salary = 140% of salaryHP = Purchase cost of any hardware requiredHI = Installation cost of any hardware requiredSL= Cost of any software licencesX/Bba = An estimate of the damage to brand image.

36. Rate CardProject Manager = $45 / hourArchitect = $46 / hourLead Developer = $41 / hourDeveloper = $36 / hourTester = $27 / hourTech. Support = $20 / hourBusiness Analyst = $44 / hour.*Hourly rate = average annual salary / (52 – 4wks AL * 5 – 9 days PH * 8 hrs)***Correct as of November ’10. YMMV 

37. Case Study #1The Anti-Pattern: Waterfall Methodology

38. The Main Weaknessof Waterfall

39. Where Does Change Come From?

40. Why is Change So Costly?

41. Why Is This Technical Debt?Borrow time now, repay laterTake advantages nowEase in analysing potential changesEase of coordinating large teamsPrecise budgetingRepay laterExtra cost of change.

42. Quantify the TechnicalDebt: AgileAssume a small error caught during the “paper prototype” phase of an iterationResources deployedArchitect spends 1 hour fixing designTester spends 1/2 hour verifying the fixApply those figures to our formula and:Cost of fixing the error = $82

43. Quantify the TechnicalDebt: WFNow the same error found in waterfall...Resources deployedArchitect 1 hour fixing designDeveloper spends 4 hours coding solutionLead developer spends ½ hour peer reviewTester spends 2 hours verifying fixApply those figures to our formula and:Cost of fixing the error = $285Value of the technical debt = $203

44. Potential Cost Per ProjectSo the TD / defect = $202The av. number of defects / project = 283*Potential TD / project = $57,166 *Source: Scan 2006 Benchmark (as of March 2008)

45. Fixing The Technical DebtI’m not saying prefer Agile over WaterfallI am saying:Be aware of the impact that might have on TDThink about how you are going to combat that:Review earlier in the process where change is cheapEnsure the SME has peer reviewRegular, early checks on design vs. coded solutionDon’t leave all testing to the last phase.

46. Case Study #2The Anti – Pattern: Not Invented Here

47. SymptomsDevelopment team spend time developing software which is not core the problem they are trying to solveInstead of buying in a third party solutionThey justify this by saying things like:It doesn’t work the way we need it toIt would take me as long to write as to learn APIThe 3rd party may go bustThe code isn’t good enough quality.

48. Concrete ExampleDevelopers for a national bank are tasked with creating a new MIS toolThey dedicate 1 developer full time to creating a charting componentThis sucks in testing and PM time tooCharting component not core to task at handSpent 3 months getting nowhereBefore buying a charting component.

49. Why Is This TechnicalDebt?Savings against time not madeChose to develop a componentShould have bought from a third party.

50. Quantifying The Technical DebtThe component was bought in the end:Disregard the cost of the componentAnd the time spent learning the APIResources deployed:1 X developer 3 months1 X tester 1.5 months1 X lead developer 1 day1 X PM 1 dayCost of technical debt : $34,050

51. Fixing The Technical DebtIdentify non core functional aspects of projectFor each of those:Can a component be bought in to achieve it?If so, buy itIf notDoes your enterprise allow open source?If so use itBeware of licence implicationsOnly after evaluating and discounting alternatives should you consider writing your own.

52. Case Study #3Anti-Pattern: Code that plays together stays together

53. SymptomsLet’s imagine a “Car” objectWhat properties should it have?MakeModelColourWhat behaviour should it have?None!It’s an inanimate object!A “Car” will have things done to it by “actors”.

54. What Is The Problem?

55. Example of Class PollutionCredit: Phil Winstanley (http://weblogs.asp.net/Plip/)

56. Why Is This TechnicalDebt?Borrow time now, repay laterBorrowed time nowSimpler object graphRepay later in cost of adding functionality.

57. Concrete ExampleOnline provider wants to be first to marketShips service with monolithic object graphEffort required to add new features growsDevelopment slows to a crawlManagement demand a fix.

58. Quantifying theTechnical Debt1 monthly iteration to fix this debtResources deployed:5 X Developers1 X lead developer2 X testersApply these figures to our formula and:Cost of technical debt: $61,290.

59. Fixing The Technical DebtUnderstand thatMonolithic object graph has a limited lifespanPrefer separation of concernsIf first to market is importantUnderstand the value of the technical debt accruedDecide when the debt will be paid offDecide if commercial gain outweighs cost of debtRefactoring tools can reduce “interest” on debt.

60. Case Study #4The Anti-Pattern: Sensitive Tests

61. SymptomsTest which are sensitive toContextInterfaceDataPass in one iterationFail in the next due to changes.

62. Why Is ThisTechnical Debt?Borrow time now, repay laterBorrowed time in the form of easy to write testsRepay later in form of fixing sensitive tests.

63. Concrete ExampleTester testing code which uses data from development databaseDeveloper adds new functionalityShape of the database changesValues in the database changePreviously passing tests failTests rewritten using current dev. database.

64. Quantifying theTechnical DebtTake previous 283 defects per projectAssume 10% of tests for those defects are data dependantAssume it takes tester 30 minutes to fix each test28 * 0.5 = 14 hoursApply those figures to our formula and:Technical debt = $536.35.

65. Fixing TheTechnical DebtTest must use independent dataDon’t run tests against development dataEitherHave a dedicated test databaseOr it may be possible to mock data access Or have the set up code for each test or suite of tests generate the data it requires and drop it during the tear down code.

66. How Do We SpotTechnical Debt?

67. We Are Used to Charting Progress

68. Time Budget FailuresAre Obvious

69. Effect #1Loss of Productivity

70. Effect #1Loss of Productivity

71. Effect #2Increase In Testing

72. Effect #2Increase In Testing

73. Effect #3Decrease In Morale

74. Effect #3Decrease In Morale

75. SummaryIn this presentation you learned:What technical debt isThat it is important to manage technical debtSome common anti-patterns and how to fix themMetrics to spot hidden technical debtHow to quantify technical debt.

76. Take AwayIf you only take away one thingKnow that technical debt isthe silent killer that stalks all projectsDon’t let it kill your projects!