Technical Debt: Do Not Underestimate The Danger


Published on

This is the slides of my latest talk about the "technical debt" concept.

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Technical Debt: Do Not Underestimate The Danger

  1. Do not underestimate the danger technical Lemİ Orhan ERGİN Principal Software Engineer @ Sony debt @lemiorhan
  2. Lemİ Orhan Ergİn Principal Software Engineer at Sony has worked in Tüsside, BYM, GittiGidiyor/eBay and Sony as lead developer, team leader, technical coordinator and scrum master got CSM certificate from Jim Coplien year as Scrum Master sprints in 4 years as team member and scrum master experienced in agile transformation and building agile culture in teams & organizations 2001 2013 2009 1 56 agile CSM, PSM1
  3. financial debt and the metaphor
  4. expensive DEBTsin every second of our lifeWe incur Living is
  5. taxes gas fuel water phone electricity rent credit cards cabletv tuition TOLLS mortgageschool payments transportation Holidays INTERNET 3g/4G municipal services shopping communication food health entombment Parking
  6. Financial debtis not always a bad thing. It lets us buy what we want or what we need and keep us live at some level.
  7. Financial debtis dangerous if the incurred interest and the debt itself are not payed
  8. Financial debt is a silent killer
  9. Financial debt hides problemsand leads to other problems
  10. technical debtis a metaphor developed by Ward Cunningham in 1992 to communicate problems due to“developing not in the right way” with non-technical stakeholders. met·a·phor noun ˈme-tə-ˌfȯr also -fər a word or phrase for one thing that is used to refer to another thing in order to show or suggest that they are similar
  11. deficit Enron financing paying the principal debt Interest on the debt bankruptcy borrowing money Intertest on the loan Inflation financial burden very similar technical debt is to financial debt
  12. the cost
  13. technical debt costs money, time and effort to stakeholders, developers, companies, even to economies
  14. most companies have to spend 80% of their software development budget maintaining code Aaron Erickson, “ ”
  15. U.S. Air Force pulls plug on ERP project after blowing through $1 billion chris kanaracus, “ ”
  16. we don’t know how much technical debt is really costing us Jim bird, “ ”
  17. Technical debt is like smoking addiction. Once you start hacking your code, the code asks for more. you never know what that will cost in the future. Lemİ Orhan ERGİN, “ ”
  18. High amount of Technical Debt is #1 impediment to teams being agile Dan Rawsthorne “ ”
  19. Sufficient amount of messy code may bring whole Engineering department to a stand-still Sven Johann & Eberhard Wolff, Infoq “ ”
  20. the description
  21. 2 ways of doing things
  22. clean and smart way takes longer to implement but make changes easier in the future
  23. quick and dirty way get your features sooner, but make the future changes very hard
  24. why should the sponsors of a project accept higher costs ? Question:
  25. why should the sponsors spend money on features that don’t deliver business value ? Question:
  26. Living with technical debt might work perfectly for customers if it delivers the desired business value Answer:
  27. but this will lead an uncontrollable codebase, extremely specialized developers and to an inflexible product
  28. Shipping firsttime code is like going into debt
  29. a little debt speeds development as it is paid back with a rewrite
  30. It’s a question of Pay me now or Pay me later
  31. good or bad
  32. ... if you have strategic design decisions. It allow rapid delivery to elicit quick feedback and correct design. However, clean code is required to pay back debt therefore the code sould be refactored ıncurring technical debt is a good idea
  33. ... if principal amount and interest is smaller than the yield of investment. Sometimes, you don't have to pay back the debt, it is pointless if the code won't be touched again ıncurring technical debt is a good idea
  34. ... because having messy code and cutting quality slows you down in reality. And you must generate more mess to keep up. Do you ask permission to do your job correctly???? ıncurring technical debt is a bad idea
  35. extend the metaphor
  36. similarities with financial debt Every minute spent on not-quite-write code counts as interest on the debt Interest Image by Martin Schoeller from “Identical: Portraits of Twins” book
  37. similarities with financial debt Refactoring is like paying off the principal debt paying the principal debt Image by Martin Schoeller from “Identical: Portraits of Twins” book
  38. similarities with financial debt Neglecting the design is like borrowing money borrowing money Image by Martin Schoeller from “Identical: Portraits of Twins” book
  39. similarities with financial debt Bankruptcy refers to a situation of overwhelming debt interest, whereby progress is halted and a complete rewrite is necessary bankruptcy Image by Martin Schoeller from “Identical: Portraits of Twins” book
  40. similarities with financial debt It occurs when the current level of technology is old enough to lose compatibility with the industry technical Inflation Image by Martin Schoeller from “Identical: Portraits of Twins” book
  41. similarities with financial debt It represents technical frauds undermine ROIs Enron Financing Image by Martin Schoeller from “Identical: Portraits of Twins” book
  42. similarities with financial debt Throw away prototypes, retired products and complete failures on will-not-be-used components does not have to be repaid amnesty Image by Martin Schoeller from “Identical: Portraits of Twins” book
  43. the Symptoms
  44. the loss of productivity We cannot measure productivity, that's why we can't really see real the true effect of technical debt and losing motivation and morale
  45. Increase in testing If the team does the same tests again and again on every release or testing takes too much time, the debt seems to be in critical level. the death by manual testing
  46. Postponed stories in releases Postponed releases It becomes harder to catch the deadlines. An increase on the postponed releases rate is an indicator. being not ready to go
  47. Code duplication Code duplication leads to update anomalies, purpose masking and issues on understanding code copy & Paste programming
  48. Low code coverage 100% coverage is the asymptotic target. Below 75% indicates serious problems. not knowing how sW behaves
  49. Increase in bugs The increase in number of bugs directly shows the decrease of quality and too much support cases
  50. heavy stress on appoaching deadlineS The team is under heavy stree at the end of releases or when the deadlines are approaching
  51. being scared of changing anything Software is so brittle that developers are scared of changing anything in the code not to break. Adding new features starts to cost more and more.
  52. Evil hacks wrong design It’s hard to detect the debt in advance, but any hacks and workarounds could cause issues in the future
  53. wrong choice of technology Not the most mature, not the newest, not the simplest... Choosing the cheapest-to-adapt is the key to pay the debt.
  54. unreadable code Developers spend 80% of development time for reading code. You cannot build if you cannot understand. hard to understand what happens
  55. decreased velocity Decreased team velocity is a good indicator for possible impediments that slows the team down even if nothing has changed
  56. Using old libraries Softwares age and cause technical debt by time. Maintenance costs are the main expenditure item. and technologies
  57. Reports of Sonar Sonar Reports Softwares age and cause technical debt by time. Maintenance costs are the main expenditure item. with technical debt plugin
  58. bad smells The indicator of weaknesses in design that may be slowing down development or increasing the risk of bugs or failures in the future “Only he knows can change this part” “Lets copy & paste this code” “If I touch, everything will break” “Too many TODOs or FIXMEs in the code”
  59. 36 classic mistakes Making mistakes is inevitable. Only experienced software developers realize when they're making mistakes. outlined in McConnell's Rapid Development
  60. the types by scope
  61. unavoidable debt Usually unpredictable and unpreventable and the team has no fault on that Due to legal issues, we have to rewrite some of the components “ ”
  62. Strategic debt Long term debt, usually incurred proactively I want to be the first in the market“ ”
  63. tactical debt It’s different that strategic by the reactive manner for the short term We don't have time to implement in the right way, just a hack. We'll fix later. “ ”
  64. Incremental debt Hundreds or thousands of small shortcuts, like credit card debt We have to do quick hacks and dirty solutions to catch the deadline “ ”
  65. INADVERTENT (naive) debt It occurs due to irresponsible behavior or immature practices on the part of the people involved We have to build the software product with inexperienced newbies “ ”
  66. the types by content
  67. Design & architectural Debt Shortcuts and shortcommings Long and detailed upfront designs Sub-optimal solutions
  68. code quality Debt Short time between failures Severe defect count Every hack, work around, bad piece of code builds Unnecessary code duplication and complexity
  69. testing Debt Missing automated tests Too much time spending for regression testing
  70. Knowledge distribution and documentation debt Only few people knows the system When all key people left the organization, the debt becomes extremely high
  71. Environmental Debt Problems in development related processes Issues in hardware, infrastructure, supporting apps Having too many manual operational tasks
  72. Monetary cost Developer’s time is expensive No developer enjoys to work on brittle and complicated code That leads turnovers and it is one of the real economic costs of technical debt
  73. the stakeholders
  74. customers Annoyed by bugs, missing features, slow lead times and expensive costs
  75. helpdesk Additional costs
  76. operations team Frequent patches and fixes
  77. management Annoyed due to bugs, delays, costs and security issues
  78. developers No one wants to develop bad code No one wants to take over bad work of others
  79. the strategic design
  80. A system can't have the same high level of quality throughout the system strategic design The team can choose which parts will have high quality or kept as low quality Consumer understands quick & dirty solutions lead to debt Understanding Strategic Design leads to better decisions from stakeholders
  81. fixing the debt
  82. Merciless refactoring
  83. fast automation
  84. share knowledge knowledge decays fast
  85. slow down to go fast
  86. clean code principles clean, readable and simple code
  87. clear definition of done showing us how to avoid incurring debt
  88. key engineering practices Pair Programming Test Driven Development Continuous Integration 10 min Builds Refactoring Automated unit tests etc. these should always directly associated with a requirement
  89. test driven development Pre-release defect density decreased 40-90% relative to similar products that do not use TDD Initial development time increased 15-35% after TDD
  90. fail fast Peer Review Code Review Don't leave all testing to the last phase
  91. Limit work-in-progress
  92. fix constantly
  93. Monitor your debt Code coverage: Monitor trends, not points Cyclomatic complexity: Number of branches in code Coupling: Interconnectedness of systems
  94. clean constantly
  95. fix root causes
  96. Follow the Boy Scout Rule quality is your responsibility
  97. never make intentional mess
  98. Never ask permission to do your job correctly
  99. The Payment strategies From Frank Buschmann
  100. debt repayment Refactor or replace code
  101. debt conversion Replace the current solution with a "good but not perfect" solution
  102. just pay the interest Live with the code Refactoring is more expensive than the work with bad code End-of-life software or will-be-retired software
  103. The Payment Approaches
  104. Minimal Iteration Debt Payment Half a day in a week
  105. Technical Backlog Debt is made visible and clear for everbody Cost per task is trackable No mixture between technical and feature tasks adv.disadv. 2 backlogs and hard to prioritize Customers may not understand the real benefits of a tech task Very expensive changes must always a business reason
  106. buffer tasks for refactoring 10% of the team's time
  107. clean-up releases
  108. The measurment
  109. time investment is actually worth it it is important to decide that
  110. even impossible to predict The effect of bad code quality for future requirements is difficult
  111. The delta from ideal Errors & warnings Code duplication Code coverage Gut feeling in large apps, the measure is basically useless
  112. Story Probing The assumption is that technical debt increases the estimate
  113. formulas to guess the debt There are many formulas proposed and used
  114. Estimate the cost of a failure and then multiply by the probability it will occur Technical debt is the cost of implementing the required redundancy
  115. the conclusion
  116. you got the red pill Understanding technical debt will let you, your team, the business and the stakeholders make better decisions
  117. Technical Debt 1 Billion Dolar Fail Evluation with Sonar 36 Classic Mistakes Calculating the ocost
  119. Lemİ orhan ergİn @lemiorhan @lemiorhan @lemiorhan LINKEDINTWITTERSLIDESHAREBLOG Principal Software Engineer @ Sony Founder & Author @