Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Credit Crunch CodePaying Back the Technical Debt<br />By Woody Pewitt<br />woodyp@devexpress.com<br />@woodyp<br />
Agenda<br />Defining Technical Debt<br />Why Managing Technical Debt is Important<br />Quantifying Technical Debt<br />Tec...
Why should do you care?<br />
Big ball of mud!<br />A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, spaghet...
Big ball of mud!<br />
How to you get them?<br />The Big Ball of Mud and Other Architectural Disasters<br />http://www.codinghorror.com<br />Jeff...
Shantytown, Spaghetti Code<br />
Throwaway Code<br />
Piecemeal Growth<br />
Keep It Working<br />
Shearing Layers<br />
Sweeping It Under The Rug<br />
Reconstruction<br />
Steve McConnell's36 classic mistakes<br />People Mistakes<br />Undermined motivation<br />Weak personnel<br />Uncontrolled...
Steve McConnell's36 classic mistakes<br />Process Mistakes<br />Overly optimistic schedules<br />Insufficient risk managem...
Steve McConnell's36 classic mistakes<br />Product Mistakes<br />Requirements gold-plating<br />Feature creep<br />Develope...
Steve McConnell's36 classic mistakes<br />Technology Mistakes<br />Silver-bullet syndrome<br />Overestimated savings from ...
So What is Technical Debt?<br />
Defining Technical Debt #1<br />Term coined by Ward Cunningham in 1992<br />Analogous to financial debt<br />Financial deb...
Defining Technical Debt #2<br />With financial debt<br />“Virtual debt” by not having the best interest rate<br />With Tec...
What is Interest On Technical Debt?<br />Cost later – cost now<br />Financial value of damage to your brand<br />Loss of m...
Just As Not All Financial Debt Is Bad<br />
Nor Is All Technical Debt<br />
But Financial Debt Can Be Dangerous<br />
And So Can Technical Debt<br />
Classes of Technical Debt<br />Planned<br />1<br />3<br />Known<br />Unknown<br />2<br />4<br />Unplanned<br />
Why Managing Technical Debt is Important?<br />
Why Is Managing Technical Debt Important?<br />
Reduce Effort by Keeping it Under Control<br />
Quantifying Technical Debt<br />
Basic Formula To Get You Started<br />Where:<br />T = Total number of employees involved in paying back the debt<br />i = ...
Rate Card<br />Project Manager = $45 / hour<br />Architect = $46 / hour<br />Lead Developer = $41 / hour<br />Developer = ...
Case Study #1<br />The Anti-Pattern: Waterfall Methodology<br />
The Main Weakness of Waterfall<br />
Where Does Change Come From?<br />
Why is Change So Costly?<br />
Why Is This Technical Debt?<br />Borrow time now, repay later<br />Take advantages now<br />Ease in analysing potential ch...
Quantify the Technical Debt: Agile<br />Assume a small error caught during the “paper prototype” phase of an iteration<br ...
Quantify the Technical Debt: WF<br />Now the same error found in waterfall...<br />Resources deployed<br />Architect 1 hou...
Potential Cost Per Project<br />So the TD / defect = $202<br />The av. number of defects / project = 283*<br />Potential T...
Fixing The Technical Debt<br />I’m not saying prefer Agile over Waterfall<br />I am saying:<br />Be aware of the impact th...
Case Study #2<br />The Anti – Pattern: Not Invented Here<br />
Symptoms<br />Development team spend time developing software which is not core the problem they are trying to solve<br />...
Concrete Example<br />Developers for a national bank are tasked with creating a new MIS tool<br />They dedicate 1 develope...
Why Is This Technical Debt?<br />Savings against time not made<br />Chose to develop a component<br />Should have bought f...
Quantifying The Technical Debt<br />The component was bought in the end:<br />Disregard the cost of the component<br />And...
Fixing The Technical Debt<br />Identify non core functional aspects of project<br />For each of those:<br />Can a componen...
Case Study #3<br />Anti-Pattern: Code that plays together stays together<br />
Symptoms<br />Let’s imagine a “Car” object<br />What properties should it have?<br />Make<br />Model<br />Colour<br />What...
What Is The Problem?<br />
Example of Class Pollution<br />Credit: Phil Winstanley (http://weblogs.asp.net/Plip/)<br />
Why Is This Technical Debt?<br />Borrow time now, repay later<br />Borrowed time now<br />Simpler object graph<br />Repay ...
Concrete Example<br />Online provider wants to be first to market<br />Ships service with monolithic object graph<br />Eff...
Quantifying the Technical Debt<br />1 monthly iteration to fix this debt<br />Resources deployed:<br />5 X Developers<br /...
Fixing The Technical Debt<br />Understand that<br />Monolithic object graph has a limited lifespan<br />Prefer separation ...
Case Study #4<br />The Anti-Pattern: Sensitive Tests<br />
Symptoms<br />Test which are sensitive to<br />Context<br />Interface<br />Data<br />Pass in one iteration<br />Fail in th...
Why Is This Technical Debt?<br />Borrow time now, repay later<br />Borrowed time in the form of easy to write tests<br />R...
Concrete Example<br />Tester testing code which uses data from development database<br />Developer adds new functionality<...
Quantifying the Technical Debt<br />Take previous 283 defects per project<br />Assume 10% of tests for those defects are d...
Fixing The Technical Debt<br />Test must use independent data<br />Don’t run tests against development data<br />Either<br...
How Do We Spot Technical Debt?<br />
We Are Used to Charting Progress<br />
Time Budget Failures Are Obvious<br />
Effect #1 – Loss of Productivity<br />
Effect #1 – Loss of Productivity<br />
Effect #2 – Increase In Testing<br />
Effect #2 – Increase In Testing<br />
Effect #3 – Decrease In Morale<br />
Effect #3 – Decrease In Morale<br />
Summary<br />In this presentation you learned:<br />What technical debt is<br />That it is important to manage technical d...
Take Away<br />If you only take away one thing<br />Know that technical debt is<br />the silent killer that stalks all pro...
Upcoming SlideShare
Loading in …5
×

Technical Debt

1,072 views

Published on

Published in: Technology
  • Be the first to comment

Technical Debt

  1. 1. Credit Crunch CodePaying Back the Technical Debt<br />By Woody Pewitt<br />woodyp@devexpress.com<br />@woodyp<br />
  2. 2. Agenda<br />Defining Technical Debt<br />Why Managing Technical Debt is Important<br />Quantifying Technical Debt<br />Technical Debt Anti-Patterns & Fixes<br />Finding Technical Debt Using Metrics<br />Summary<br />Further Reading<br />Questions.<br />
  3. 3. Why should do you care?<br />
  4. 4. Big ball of mud!<br />A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, spaghetti-code jungle.<br />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.<br />People who maintain such systems, are often seen wearing socks and sandals.<br />
  5. 5. Big ball of mud!<br />
  6. 6. How to you get them?<br />The Big Ball of Mud and Other Architectural Disasters<br />http://www.codinghorror.com<br />Jeff Atwood<br />On Joseph Yoder's Big Ball of Mud paper<br />
  7. 7. Shantytown, Spaghetti Code<br />
  8. 8. Throwaway Code<br />
  9. 9. Piecemeal Growth<br />
  10. 10. Keep It Working<br />
  11. 11. Shearing Layers<br />
  12. 12. Sweeping It Under The Rug<br />
  13. 13. Reconstruction<br />
  14. 14. Steve McConnell's36 classic mistakes<br />People Mistakes<br />Undermined motivation<br />Weak personnel<br />Uncontrolled problem employees<br />Heroics<br />Adding people to a late project<br />Noisy, crowded offices<br />Friction between developers and customers<br />Unrealistic expectations<br />Lack of effective project sponsorship<br />Lack of stakeholder buy-in<br />Lack of user input<br />Politics placed over substance<br />Wishful thinking<br />
  15. 15. Steve McConnell's36 classic mistakes<br />Process Mistakes<br />Overly optimistic schedules<br />Insufficient risk management<br />Contractor failure<br />Insufficient planning<br />Abandonment of planning under pressure<br />Wasted time during the fuzzy front end<br />Shortchanged upstream activities<br />Inadequate design<br />Shortchanged quality assurance<br />Insufficient management controls<br />Premature or too frequent convergence<br />Omitting necessary tasks from estimates<br />Planning to catch up later<br />Code-like-hell programming<br />
  16. 16. Steve McConnell's36 classic mistakes<br />Product Mistakes<br />Requirements gold-plating<br />Feature creep<br />Developer gold-plating<br />Push me, pull me negotiation<br />Research-oriented development<br />
  17. 17. Steve McConnell's36 classic mistakes<br />Technology Mistakes<br />Silver-bullet syndrome<br />Overestimated savings from new tools or methods<br />Switching tools in the middle of a project<br />Lack of automated source control<br />
  18. 18.
  19. 19. So What is Technical Debt?<br />
  20. 20. Defining Technical Debt #1<br />Term coined by Ward Cunningham in 1992<br />Analogous to financial debt<br />Financial debt = borrow money against a future date<br />Technical debt = borrow time against a future date.<br />
  21. 21. Defining Technical Debt #2<br />With financial debt<br />“Virtual debt” by not having the best interest rate<br />With Technical Debt<br />Not making savings against time where possible.<br />
  22. 22. What is Interest On Technical Debt?<br />Cost later – cost now<br />Financial value of damage to your brand<br />Loss of market share<br />Low staff morale<br />
  23. 23. Just As Not All Financial Debt Is Bad<br />
  24. 24. Nor Is All Technical Debt<br />
  25. 25. But Financial Debt Can Be Dangerous<br />
  26. 26. And So Can Technical Debt<br />
  27. 27. Classes of Technical Debt<br />Planned<br />1<br />3<br />Known<br />Unknown<br />2<br />4<br />Unplanned<br />
  28. 28. Why Managing Technical Debt is Important?<br />
  29. 29. Why Is Managing Technical Debt Important?<br />
  30. 30. Reduce Effort by Keeping it Under Control<br />
  31. 31. Quantifying Technical Debt<br />
  32. 32. Basic Formula To Get You Started<br />Where:<br />T = Total number of employees involved in paying back the debt<br />i = The individual employee<br />HRi = Hourly rate of pay for that individual<br />Hi = The hours that an individual worked in paying back the debt<br />EOC = Employer’s on cost – estimated at 40% of salary = 140% of salary<br /> HP = Purchase cost of any hardware required<br /> HI = Installation cost of any hardware required<br /> SL= Cost of any software licences<br /> X/Bba = An estimate of the damage to brand image.<br />
  33. 33. Rate Card<br />Project Manager = $45 / hour<br />Architect = $46 / hour<br />Lead Developer = $41 / hour<br />Developer = $36 / hour<br />Tester = $27 / hour<br />Tech. Support = $20 / hour<br />Business Analyst = $44 / hour.<br />*Hourly rate = average annual salary / (52 – 4wks AL * 5 – 9 days PH * 8 hrs)<br />***Correct as of November ’10. YMMV <br />
  34. 34. Case Study #1<br />The Anti-Pattern: Waterfall Methodology<br />
  35. 35. The Main Weakness of Waterfall<br />
  36. 36. Where Does Change Come From?<br />
  37. 37. Why is Change So Costly?<br />
  38. 38. Why Is This Technical Debt?<br />Borrow time now, repay later<br />Take advantages now<br />Ease in analysing potential changes<br />Ease of coordinating large teams<br />Precise budgeting<br />Repay later<br />Extra cost of change.<br />
  39. 39. Quantify the Technical Debt: Agile<br />Assume a small error caught during the “paper prototype” phase of an iteration<br />Resources deployed<br />Architect spends 1 hour fixing design<br />Tester spends 1/2 hour verifying the fix<br />Apply those figures to our formula and:<br />Cost of fixing the error = $82<br />
  40. 40. Quantify the Technical Debt: WF<br />Now the same error found in waterfall...<br />Resources deployed<br />Architect 1 hour fixing design<br />Developer spends 4 hours coding solution<br />Lead developer spends ½ hour peer review<br />Tester spends 2 hours verifying fix<br />Apply those figures to our formula and:<br />Cost of fixing the error = $285<br />Value of the technical debt = $203<br />
  41. 41. Potential Cost Per Project<br />So the TD / defect = $202<br />The av. number of defects / project = 283*<br />Potential TD / project = $57,166 <br />*Source: Scan 2006 Benchmark (as of March 2008)<br />
  42. 42. Fixing The Technical Debt<br />I’m not saying prefer Agile over Waterfall<br />I am saying:<br />Be aware of the impact that might have on TD<br />Think about how you are going to combat that:<br />Review earlier in the process where change is cheap<br />Ensure the SME has peer review<br />Regular, early checks on design vs coded solution<br />Don’t leave all testing to the last phase.<br />
  43. 43. Case Study #2<br />The Anti – Pattern: Not Invented Here<br />
  44. 44. Symptoms<br />Development team spend time developing software which is not core the problem they are trying to solve<br />Instead of buying in a third party solution<br />They justify this by saying things like:<br />It doesn’t work the way we need it to<br />It would take me as long to write as to learn API<br />The 3rd party may go bust<br />The code isn’t good enough quality.<br />
  45. 45. Concrete Example<br />Developers for a national bank are tasked with creating a new MIS tool<br />They dedicate 1 developer full time to creating a charting component<br />This sucks in testing and PM time too<br />Charting component not core to task at hand<br />Spent 3 months getting nowhere<br />Before buying a charting component.<br />
  46. 46. Why Is This Technical Debt?<br />Savings against time not made<br />Chose to develop a component<br />Should have bought from a third party.<br />
  47. 47. Quantifying The Technical Debt<br />The component was bought in the end:<br />Disregard the cost of the component<br />And the time spent learning the API<br />Resources deployed:<br />1 X developer 3 months<br />1 X tester 1.5 months<br />1 X lead developer 1 day<br />1 X PM 1 day<br />Cost of technical debt : $34,050<br />
  48. 48. Fixing The Technical Debt<br />Identify non core functional aspects of project<br />For each of those:<br />Can a component be bought in to achieve it?<br />If so, buy it<br />If not<br />Does your enterprise allow open source?<br />If so use it<br />Beware of licence implications<br />Only after evaluating and discounting alternatives should you consider writing your own.<br />
  49. 49. Case Study #3<br />Anti-Pattern: Code that plays together stays together<br />
  50. 50. Symptoms<br />Let’s imagine a “Car” object<br />What properties should it have?<br />Make<br />Model<br />Colour<br />What behaviour should it have?<br />None!<br />It’s an inanimate object!<br />A “Car” will have things done to it by “actors”.<br />
  51. 51. What Is The Problem?<br />
  52. 52. Example of Class Pollution<br />Credit: Phil Winstanley (http://weblogs.asp.net/Plip/)<br />
  53. 53. Why Is This Technical Debt?<br />Borrow time now, repay later<br />Borrowed time now<br />Simpler object graph<br />Repay later in cost of adding functionality.<br />
  54. 54. Concrete Example<br />Online provider wants to be first to market<br />Ships service with monolithic object graph<br />Effort required to add new features grows<br />Development slows to a crawl<br />Management demand a fix.<br />
  55. 55. Quantifying the Technical Debt<br />1 monthly iteration to fix this debt<br />Resources deployed:<br />5 X Developers<br />1 X lead developer<br />2 X testers<br />Apply these figures to our formula and:<br />Cost of technical debt: $61,290.<br />
  56. 56. Fixing The Technical Debt<br />Understand that<br />Monolithic object graph has a limited lifespan<br />Prefer separation of concerns<br />If first to market is important<br />Understand the value of the technical debt accrued<br />Decide when the debt will be paid off<br />Decide if commercial gain outweighs cost of debt<br />Refactoring tools can reduce “interest” on debt.<br />
  57. 57. Case Study #4<br />The Anti-Pattern: Sensitive Tests<br />
  58. 58. Symptoms<br />Test which are sensitive to<br />Context<br />Interface<br />Data<br />Pass in one iteration<br />Fail in the next due to changes.<br />
  59. 59. Why Is This Technical Debt?<br />Borrow time now, repay later<br />Borrowed time in the form of easy to write tests<br />Repay later in form of fixing sensitive tests.<br />
  60. 60. Concrete Example<br />Tester testing code which uses data from development database<br />Developer adds new functionality<br />Shape of the database changes<br />Values in the database change<br />Previously passing tests fail<br />Tests rewritten using current dev. database.<br />
  61. 61. Quantifying the Technical Debt<br />Take previous 283 defects per project<br />Assume 10% of tests for those defects are data dependant<br />Assume it takes tester 30 minutes to fix each test<br />28 * 0.5 = 14 hours<br />Apply those figures to our formula and:<br />Technical debt = $536.35.<br />
  62. 62. Fixing The Technical Debt<br />Test must use independent data<br />Don’t run tests against development data<br />Either<br />Have a dedicated test database<br />Or it may be possible to mock data access <br />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.<br />
  63. 63. How Do We Spot Technical Debt?<br />
  64. 64. We Are Used to Charting Progress<br />
  65. 65. Time Budget Failures Are Obvious<br />
  66. 66. Effect #1 – Loss of Productivity<br />
  67. 67. Effect #1 – Loss of Productivity<br />
  68. 68. Effect #2 – Increase In Testing<br />
  69. 69. Effect #2 – Increase In Testing<br />
  70. 70. Effect #3 – Decrease In Morale<br />
  71. 71. Effect #3 – Decrease In Morale<br />
  72. 72. Summary<br />In this presentation you learned:<br />What technical debt is<br />That it is important to manage technical debt<br />Some common anti-patterns and how to fix them<br />Metrics to spot hidden technical debt<br />How to quantify technical debt.<br />
  73. 73. Take Away<br />If you only take away one thing<br />Know that technical debt is<br />the silent killer that stalks all projects<br />Don’t let it kill your projects!<br />
  74. 74. Further Reading<br />http://c2.com/cgi/wiki?WardExplainsDebtMetaphor<br />http://c2.com/cgi/wiki?TechnicalDebt<br />http://blogs.construx.com/blogs/stevemcc/archive/2007/11/01/technical-debt-2.aspx<br />http://www.martinfowler.com/bliki/TechnicalDebt.html<br />
  75. 75. Questions?<br />There wasn’t time for my question<br />Where can I contact you?<br />woodyp@devexpress.com<br />www.devexpress.com/woody<br />On Twitter as @woodypewitt<br />

×