Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
Credit Crunch Code<br />Paying Back the Technical Debt<br />By Gary Short<br />1<br />
Agenda<br />Defining Technical Debt<br />Why Managing Technical Debt is Important<br />Quantifying Technical Debt<br />Tec...
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...
Is There Interest On Technical Debt?<br />Just as there is interest on financial debt...<br />So there is interest on tech...
Just As Not All Financial Debt Is Bad<br />6<br />
Nor Is All Technical Debt<br />7<br />
But Financial Debt Can Be Dangerous<br />8<br />
And So Can Technical Debt<br />9<br />
Why Is Managing Technical Debt Important?<br />10<br />
Reduce Effort by Keeping it Under Control<br />11<br />
Quantifying Technical Debt<br />12<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 = 32 Euros / hour<br />Architect = 33 Euros / hour<br />Lead Developer = 30 Euros / hour<br...
Case Study #1<br />The Anti-Pattern: Waterfall Methodology<br />15<br />
The Main Weakness of Waterfall<br />16<br />
Where Does Change Come From?<br />17<br />
Why is Change So Costly?<br />18<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: BDUF<br />Now the same error found in waterfall...<br />Resources deployed<br />Architect 1 h...
Potential Cost Per Project<br />So the TD / defect = 148 Euros<br />The av. number of defects / project = 283*<br />Potent...
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 />24<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 />30<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 />32<br />
Example of Class Pollution<br />Credit: Phil Winstanley (http://weblogs.asp.net/Plip/)<br />33<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 />38<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 />44<br />
We Are Used to Charting Progress<br />45<br />
Time Budget Failures Are Obvious<br />46<br />
Effect #1 – Loss of Productivity<br />47<br />
Effect #1 – Loss of Productivity<br />48<br />
Effect #2 – Increase In Testing<br />49<br />
Effect #2 – Increase In Testing<br />50<br />
Effect #3 – Decrease In Morale<br />51<br />
Effect #3 – Decrease In Morale<br />52<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...
Further Reading<br />http://c2.com/cgi/wiki?WardExplainsDebtMetaphor<br />http://c2.com/cgi/wiki?TechnicalDebt<br />http:/...
Questions?<br />There wasn’t time for my question<br />Where can I contact you?<br />gary@garyshort.org<br />www.garyshort...
Prochain SlideShare
Chargement dans…5
×

Technical Debt

17 538 vues

Publié le

A presentation on Technical Debt covering definition, anti-patterns, metrics, quantifying and managing.

  • Soyez le premier à commenter

Technical Debt

  1. Credit Crunch Code<br />Paying Back the Technical Debt<br />By Gary Short<br />1<br />
  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 />2<br />
  3. 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 />3<br />
  4. 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 />4<br />
  5. Is There Interest On Technical Debt?<br />Just as there is interest on financial debt...<br />So there is interest on technical debt too:<br />Cost later – cost now<br />Financial value of damage to your brand<br />Loss of market share<br />Low staff morale.<br />5<br />
  6. Just As Not All Financial Debt Is Bad<br />6<br />
  7. Nor Is All Technical Debt<br />7<br />
  8. But Financial Debt Can Be Dangerous<br />8<br />
  9. And So Can Technical Debt<br />9<br />
  10. Why Is Managing Technical Debt Important?<br />10<br />
  11. Reduce Effort by Keeping it Under Control<br />11<br />
  12. Quantifying Technical Debt<br />12<br />
  13. 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 />13<br />
  14. Rate Card<br />Project Manager = 32 Euros / hour<br />Architect = 33 Euros / hour<br />Lead Developer = 30 Euros / hour<br />Developer = 26 Euros / hour<br />Tester = 20 Euros / hour<br />Tech. Support = 15 Euros / hour<br />Business Analyst = 32 Euros / hour.<br />*Hourly rate = average annual salary / (52 – 5wks AL * 5 – 9 days PH * 8 hrs)<br />**UK hourly rate converted to Euros via Google <br />***Correct as of November ’09. YMMV <br />14<br />
  15. Case Study #1<br />The Anti-Pattern: Waterfall Methodology<br />15<br />
  16. The Main Weakness of Waterfall<br />16<br />
  17. Where Does Change Come From?<br />17<br />
  18. Why is Change So Costly?<br />18<br />
  19. 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 />19<br />
  20. 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 = 60 Euros.<br />20<br />
  21. Quantify the Technical Debt: BDUF<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 = 208 Euros<br />Value of the technical debt = 148 Euros.<br />21<br />
  22. Potential Cost Per Project<br />So the TD / defect = 148 Euros<br />The av. number of defects / project = 283*<br />Potential TD / project = 41,884 Euros. <br />*Source: Scan 2006 Benchmark (as of March 2008)<br />22<br />
  23. 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 />23<br />
  24. Case Study #2<br />The Anti – Pattern: Not Invented Here<br />24<br />
  25. 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 />25<br />
  26. 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 />26<br />
  27. 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 />27<br />
  28. 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 : 24,886 Euros<br />28<br />
  29. 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 />29<br />
  30. Case Study #3<br />Anti-Pattern: Code that plays together stays together<br />30<br />
  31. 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 />31<br />
  32. What Is The Problem?<br />32<br />
  33. Example of Class Pollution<br />Credit: Phil Winstanley (http://weblogs.asp.net/Plip/)<br />33<br />
  34. 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 />34<br />
  35. 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 />35<br />
  36. 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: 44,800 Euros.<br />36<br />
  37. 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 />37<br />
  38. Case Study #4<br />The Anti-Pattern: Sensitive Tests<br />38<br />
  39. 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 />39<br />
  40. 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 />40<br />
  41. 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 />41<br />
  42. 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 = 392 Euros.<br />42<br />
  43. 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 />43<br />
  44. How Do We Spot Technical Debt?<br />44<br />
  45. We Are Used to Charting Progress<br />45<br />
  46. Time Budget Failures Are Obvious<br />46<br />
  47. Effect #1 – Loss of Productivity<br />47<br />
  48. Effect #1 – Loss of Productivity<br />48<br />
  49. Effect #2 – Increase In Testing<br />49<br />
  50. Effect #2 – Increase In Testing<br />50<br />
  51. Effect #3 – Decrease In Morale<br />51<br />
  52. Effect #3 – Decrease In Morale<br />52<br />
  53. 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 />53<br />
  54. 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 />54<br />
  55. 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 />55<br />
  56. Questions?<br />There wasn’t time for my question<br />Where can I contact you?<br />gary@garyshort.org<br />www.garyshort.org<br />On Twitter as @garyshort.<br />56<br />

×