Your SlideShare is downloading. ×
Technical debt
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Technical debt


Published on

This is my slides I used for my DevConnections Technical debt talk.

This is my slides I used for my DevConnections Technical debt talk.

  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide
  • To help management understand the cost of a…
  • I've increasingly come to believe the only difference between experienced and inexperienced software developers is that the experienced ones realize when they're making mistakes. The same rule applies to software projects and project managers. If you're not actively scanning through the list of Classic Software Development Mistakes as you run your software project, you have no idea how likely it is you're making one of these mistakes right now.
  • In the current downturn lots of companies carried low amounts of well managed financial debt and still went bankrupt when their, previously stable, line of credit was withdrawn by the banks.
  • Unforeseen things happenTeam members get:SickMove to other rolesBetter job offersYour market can:CollapseGain a new competitorExpand faster than you thought
  • Cost per feature over time
  • Cost per feature over time
  • Bad news: Quantifying Technical Debt is hardGood news: Doesn’t matter how you do itProvided:It’s meaningful to your enterpriseYou are consistent.
  • You can’t see technical debtSo how do spot something you can’t see?Astronomers have the same problemPlanets that could support life can’t be seen:Life supporting planets must be close to starsThe light from the star hides the planetSo how to they spot the planets?They look for the effect the hidden planet hasWe can do the same with technical debt.
  • Transcript

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