Successfully reported this slideshow.
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,054 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 />

×