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.

SPR Consulting Technical Debt

  • Be the first to comment

  • Be the first to like this

SPR Consulting Technical Debt

  2. 2. STRATEGY BUILD INTEGRATE TEST MANAGE Our mission is to make enterprises more efficient. Our MOBILE DATA CLOUD SOCIAL Our Services
  3. 3. AGENDA • What is technical debt? • The primary types and causes of technical debt • The consequences of technical debt • Communicating the impact of technical debt • Managing technical debt
  4. 4. WHAT IS TECHNICAL DEBT? A term used to describe the obligation that a software organization incurs when it chooses a design or construction approach that is expedient in the short term but that increases complexity and is more costly in the long term
  5. 5. TECHNICAL DEBT LAYMAN’S DEFINITION The impact of developing an imperfect product over time that becomes harder to maintain until the point where it becomes unmaintainable
  6. 6. TECHNICAL DEBT INCLUDES • Unfit or bad product design • Product defects • Incomplete testing • Poor integration and release management • Lack of system / platform experience • Good Developers, Bad Developers and even Excellent Developers! “It’s the Karma of Coding: Pay later for what you do now”
  8. 8. TYPES OF TECHNICAL DEBTCAUSES 1. Naïve technical debt 2. Unavoidable technical debt 3. Strategic technical debt • Naïve technical debt – Lack of experience • Unavoidable technical debt – advancements not available at the time • Strategic technical debt – Management decision due often to o Pressure to meet deadlines o Attempts to unreasonably accelerate velocity
  9. 9. NAIVE DEBT EXAMPLES • Lack of experience • Copy/paste programming • Poor estimation • Conforming to existing software’s poor design
  10. 10. UNAVOIDABLE DEBT EXAMPLES • Scope Creep • Third Party estimates • Change in team makeup • Late integration • New and updated development tools and methodologies • New design patterns
  11. 11. STRATEGIC DEBT EXAMPLES • Pressure to deliver • Management that requests a team to work beyond their capabilities • Survival measures
  12. 12. CONSEQUENCES OF TECHNICAL DEBT • Increased Time to Delivery • Rising Development and Support Costs • Significant Number of Defects • Unpredictable Tipping Point • Product Atrophy • Decreased Predictability • Underperformance • Universal Frustration • End Users “Got No Satisfaction”
  13. 13. TECHNICAL DEBT FINANCIAL COMPARISON • Maintaining an application without any unit tests is like borrowing money each time you add or change a line of code • Skipping design phase is like borrowing money to get a very “quick” and “predictable” return of investment • Refactoring is like paying down the principal • Development productivity decreases when interests grow up • Managers don’t care about code quality, just ask them to pay the debt in order get their attention • Bankruptcy is logical extension of technical debt uncontrolled… we call it a system rewrite
  14. 14. LET’S PLAY A GAME
  16. 16. SO WHAT CAN WE DO?
  18. 18. PAYING TECHNICAL DEBT • Happened-upon Technical Debt – Debt the team was unaware of until exposed during normal maintenance. • Known Technical Debt – Known by the development team and made visible • Targeted Technical Debt – Known by the development team and targeted for servicing by putting into the product backlog • “Suddenly Born” Technical Debt – Code built on assumptions that changes with new requirements
  19. 19. MANAGING THE ACCRUAL OF TECHNICAL DEBT • Simple Design – Follow standard software design patterns • Code Reviews – Reviews of source code by peers to increase quality and decrease technical debt • Pair Programming – Address debt together while coding • (A)TDD / BDD – (Acceptance) Test Driven Development and Behavior Driven Development to incorporate testing and requirements validation that initially fail as the code is built • Automated Testing – Ensure new development does not break existing functionality • Continuous Integration – Teams integrate their work as frequently as is practical (small delivery batches)
  20. 20. MANAGING THE ACCRUAL OF TECHNICAL DEBT (CON’T) • Refactoring – Restructure existing computer code without changing its behavior to simplify and improve code maintainability • Clear Definition of Done – This should include guidelines for code that has been reviewed and refactored • Code Guidelines – Coding conventions for standard practices and principles which include naming conventions • Standard naming Conventions – Consistency of code development to simplify maintenance & remove technical debt • Documentation – Incremental documenting • Retrospectives – Focus on Technical Debt improvements
  22. 22. MAKING TECHNICAL DEBT VISIBLE • Show declining velocity due to not addressing technical debt • Explain how cost of incremental time to repay debt and lifetime interest payments for not addressing technical debt early • Do a direct comparison of addressing technical debt versus avoiding technical debt • Remember to put as much detail and estimation process as possible • Tools like SonarQube can help the team with the time (and therefore cost) it will take to pay the debt
  23. 23. MANAGING THE ACCRUAL OF TECHNICAL DEBT - TOOLS • SonarQube – Will give a general technical debt calculation • The team will have to augment this calculation since it is incomplete and doesn’t factor team capacity and specifics of technical debt • However, SonarQube addresses the seven “deadly sins of source code quality” with this tool 1. Bad distribution of the complexity 2. Duplications 3. Lack of Comments 4. Coding Rules violations 5. Potential Bugs 6. No or Useless Unit Tests 7. Bad Design
  24. 24. MANAGING THE ACCRUAL OF TECHNICAL DEBT - TOOLS • CAST – Measures Technical Debt • Per the CAST Research Labs, the average Technical Debt per Line of Code (LOC) is $3.61
  25. 25. NUMERICAL COMPARISON Cost Manage Debt Ignore Debt Monthly Development Cost 100,000.00$ 100,000.00$ Total Development Months 13 10 Total Development Cost 1,300,000.00$ 1,000,000.00$ Delay in months (to release) 3 0 Delay cost per month 150,000.00$ 150,000.00$ Total delay cost 450,000.00$ -$ Debt-servicing months 0 4 Debt-servicing cost -$ 400,000.00$ Total cost in lifecycle profits 1,750,000.00$ 1,400,000.00$ Delay cost of incremental time to repay debt -$ 150,000.00$ Lifetime interest payments on technical debt -$ 400,000.00$ Other debt-related costs -$ 50,000.00$ Real cost in lifecycle profits 1,750,000.00$ 2,000,000.00$
  26. 26. QUANTIFYING TECHNICAL DEBT Balance Sheet FY-2015 FY-2016 Current Assets Cash 650000 700000 Accounts receivable 450000 500000 Tools and Equipment 250000 300000 Total 1350000 1500000 Total Assets 1350000 1500000 Current Liabilities Notes Payable 100000 120000 Accounts Payable 75000 85000 Short Term Technical Debt 75000 100000 Total 250000 305000 Long-term Liabilities Notes Payable 300000 320000 Long Term Technical Debt 700000 925000 Total 1000000 1245000 Total Liabilities & Stockholder Equity 1250000 1550000
  27. 27. NOT ALL TECHNICAL DEBT SHOULD BE REPAID • Product Nearing End of Life • Throwaway Prototype • Product Built for a Short Life
  28. 28. TECHNICAL DEBT SERVICING GUIDELINES • Apply the Boy Scout Rule • Repay Technical Debt Incrementally and frequently • Repay the High Interest Technical Debt first • Never, ever pay debt for unused features • Repay Technical Debt while still delivering Features It’s like a tight rope walk where spending not enough time will lead to issues and spending too much time is wasteful…
  29. 29. JEFF SHURTS
  31. 31. A SIMPLE METAPHOR… • You, the Product Owner of a mid-sized data center, need to replace a couple servers in the main rack, as they are near end-of-life.
  32. 32. A SIMPLE METAPHOR… • Your IT guy tells you it’s going to take a week. You can’t imagine why – it’s quite a simple request.
  33. 33. A SIMPLE METAPHOR… What you think the data center looks like:
  34. 34. A SIMPLE METAPHOR… What the data center really looks like:
  35. 35. ALL THAT TO SAY THIS… As Product Owners and ScrumMasters, it’s hard to know when developers are “making excuses,” and when they really have legitimate concerns.
  36. 36. BE A “PROGRAMMER WHISPERER” There are things we need to understand about the developer psyche: • We want to deliver great things! • We want to exceed expectations! • We are inherently lazy – and that’s a good thing! • We can tend to see the world through a binary, “it’s good or it’s crap” lens.
  37. 37. TRUST US, BUT BE INQUISITIVE • Do give us the time we need to maintain a tidy house. We live in it every day, and it will help us help you. • Don’t allow us to let perfect be the enemy of good. • Be on the lookout for violations of other Agile principles like YAGNI. • Keep us honest. If you give us time to refactor or clean up a code base, expect our estimates for related work to be decreased. If you have time and patience to do it, actually measure the ROI of a large refactoring effort.
  38. 38. IN SUMMARY
  39. 39. CONTACT INFO / RESOURCES Michael Dougherty – Twitter: @doughertymic Jeff Shurts – Twitter: @pknbo864 • Essential Scrum – Kenneth Rubin • Managing Software Debt: Building for the Inevitable – Chris Sterling • Wikipedia – Technical Debt, Acceptance Test Driven Development • Martin Fowler - • Clean Code – Robert C. Martin
  40. 40. RECENT NEWS ARTICLES • Software Development Times - debt-care/ • Huffington Post - blank/organizational-debt-is-li_b_7317728.html
  41. 41. 233 S. Wacker Drive | Suite 3500 Chicago, IL 60606 312.756.1760 MICHAEL DOUGHERTY JEFF SHURTS

    Be the first to comment

    Login to see the comments


Total views


On Slideshare


From embeds


Number of embeds