SlideShare a Scribd company logo

Technical debt strategy

•
•
M
Masas Dani

This document discusses the concept of technical debt in software development. It defines technical debt as the implied cost of additional rework caused by choosing an easy short-term solution rather than a better long-term approach. It then provides examples of common causes of technical debt, such as business pressure and lack of testing. Finally, it discusses strategies for managing technical debt, such as prioritizing and reducing existing debt, using debt ceilings to avoid accumulating too much debt, and focusing on recent code changes when reducing debt.

Related slideshows

Test-Driven development; why you should never code without it
Test-Driven development; why you should never code without itTest-Driven development; why you should never code without it
Test-Driven development; why you should never code without it
 
Always Be Deploying. How to make R great for machine learning in (not only) E...
Always Be Deploying. How to make R great for machine learning in (not only) E...Always Be Deploying. How to make R great for machine learning in (not only) E...
Always Be Deploying. How to make R great for machine learning in (not only) E...
 
What's Wrong with Your SDR and How to Fix It (Pat Hillery)
What's Wrong with Your SDR and How to Fix It (Pat Hillery)What's Wrong with Your SDR and How to Fix It (Pat Hillery)
What's Wrong with Your SDR and How to Fix It (Pat Hillery)
 
1 of 29
Download to read offline
Technical Debt Strategy @masasdani
is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer. https://en.wikipedia.org/wiki/Technical_debt
–Martin Fowler “…while you're programming, you are learning. It's often the case that it can take a year of programming on a project before you understand what the best design approach should have been… the moment you realize what the design should have been, you also realize that you have an inadvertent debt.” https://martinfowler.com/bliki/TechnicalDebtQuadrant.html
Common Causes • Business Pressure • Poorly Planned Product Experience • Lack of Ownership • Poor Testing Practice • … Chris Oentojo - Gojek
Technical debt strategy
Martin Fowler’s Technical Debt Quadrant
Categories • Architectural Debt • Testing Debt • Code Standar Debt • Infrastructure Debt • Knowledge Debt https://tech.ticketmaster.com/2015/06/30/what-ticketmaster-is-doing-about-technical-debt/
Minimum Viable Product (MVP): Simple functional prototype. If it makes no sense, we through away the code. First to Market Strategy Advantages: The right product, will get traction, and then investment. Disadvantages: • Our cost is our own time. • We may through away the code.
Productivity = | Features | / unit of time First Formula Feature = refactor + test + code + build + review and as a result.. the code becomes our own specification
Productivity = | Features | + | Bugs | / unit of time After Gaining Traction Feature = refactor + test + code + build + review
Technical debt strategy
How to manage technical debt? Without stopping new feature of course
Sprint = feature + bug fix + improvement Strategy Tactic Health
Technical Debt Management Strategy 1. Measure all: Do not repeat the same error. It is NOT only about our quality standards (code), it is about how fast I continue delivering it and make it work. Feature = refactor + test + code + build + review 2. Control not increasing it, with a Quality Gate & Code review. What about deadlines? 3. Prioritize & Reduce the existing one (i.e Merciless approach) https://www.slideshare.net/RaquelPau/technical-debt-management-strategies
Use debt ceiling to avoid a vicious cycle
merciless approach: create a new cleanup column
Firebreaks needed? In steady state
Knowledge Debt Measures: • How much time I need to spent to understand the existing architecture before applying a change? Consequences: • Architecture degradation • Redesign existing frameworks or reinvent the wheel. • A cascade of bugs Solutions: • External Formation • Internal Formation (Stand-ups, Code Review, Pair Programming, Tests)
Infrastructure Debt Measures: • How much time I need to spent to deploy a new version? • How much time I need to revert a new version? Consequences: • New versions appears after a long time.. • Super long working days. Solutions: • Define a collaboration workflow and tagging procedure. • Define a repository for software artifacts and Docker images. • Use software (e.g Kubernates, Puppet) to just deploy/revert changes automatically.
Architectural Debt Measures: • How much effort is needed to achieve a low coupling and high cohesion? • How much effort is needed to split the development? – Open / Close principle Consequences: • Duplicated code (SonarQube, PMD). • High cyclomatic complexity (SonarQube, PMD). • Broken Windows Theory. Solutions: • Code Review – Check SOLID principles. • Static Code analysis tools (SonarQube, PMD).
Architectural Debt A time based approach: Adam Tornhill • Most of your code is not important. Focus on the recent/new features. • Hotspot analysis to prioritize improvements Open-Close semantics validation (using Git). • Complexity Trend analysis to understand how an specific component evolves (using Git).
A time based approach: Adam Tornhill • Most of your code is not important. Focus on the recent/new features. • Hotspot analysis to prioritize improvements Open-Close semantics validation (using Git). • Complexity Trend analysis to understand how an specific component evolves (using Git).
An estimation approach: ticketmaster https://tech.ticketmaster.com/2015/06/30/what-ticketmaster-is-doing-about-technical-debt/
Testing Debt Measures: • How much code coverage do we have? • How much time we wait to run our tests? • How much time do we spent to manually validate the functionality? Consequences: • Bugs (FindBugs) • Low code coverage (SonarQube) • Slow validations / code reviews. Solutions: • BDD or TDD • Continuous Integration tools. • Code Coverage tools. • Static Code Analysis tools (SonarQube, FindBugs) 
 Do not loose time running unrelated tests • Split the project into sub-projects (e.g microservices) as much as possible. • Run integration/application tests from the CI. • You will not receive interruptions for lack of resources.
– Joshua Lewis “unit tests are the most, not the foundation”
Code Standards Debt Measures: • How much code violates our coding standards? • How much clear are our names? Consequences: • We spend more time understanding code Solutions: • Static Code Analysis tools • Continuous Inspection • There are a lot of static code analysis tools and linters for every programing language. https://www.sonarqube.org/ https://pmd.github.io/ http://checkstyle.sourceforge.net/ 
 • Every day appear more software to fix code style issues, which reduces the effort to have clean code. http://errorprone.info/
Technical Debt Distribution https://martinfowler.com/bliki/EstimatedInterest.html
–Henrik Kniberg, Spotify, Lego “old debt is bad and new debt is good.” http://blog.crisp.se/2013/10/11/henrikkniberg/good-and-bad-technical-debt
masas@mailtarget.co Thanks

More Related Content

Technical debt strategy

  • 2. is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer. https://en.wikipedia.org/wiki/Technical_debt
  • 3. –Martin Fowler “…while you're programming, you are learning. It's often the case that it can take a year of programming on a project before you understand what the best design approach should have been… the moment you realize what the design should have been, you also realize that you have an inadvertent debt.” https://martinfowler.com/bliki/TechnicalDebtQuadrant.html
  • 4. Common Causes • Business Pressure • Poorly Planned Product Experience • Lack of Ownership • Poor Testing Practice • … Chris Oentojo - Gojek
  • 7. Categories • Architectural Debt • Testing Debt • Code Standar Debt • Infrastructure Debt • Knowledge Debt https://tech.ticketmaster.com/2015/06/30/what-ticketmaster-is-doing-about-technical-debt/
  • 8. Minimum Viable Product (MVP): Simple functional prototype. If it makes no sense, we through away the code. First to Market Strategy Advantages: The right product, will get traction, and then investment. Disadvantages: • Our cost is our own time. • We may through away the code.
  • 9. Productivity = | Features | / unit of time First Formula Feature = refactor + test + code + build + review and as a result.. the code becomes our own specification
  • 10. Productivity = | Features | + | Bugs | / unit of time After Gaining Traction Feature = refactor + test + code + build + review
  • 12. How to manage technical debt? Without stopping new feature of course
  • 13. Sprint = feature + bug fix + improvement Strategy Tactic Health
  • 14. Technical Debt Management Strategy 1. Measure all: Do not repeat the same error. It is NOT only about our quality standards (code), it is about how fast I continue delivering it and make it work. Feature = refactor + test + code + build + review 2. Control not increasing it, with a Quality Gate & Code review. What about deadlines? 3. Prioritize & Reduce the existing one (i.e Merciless approach) https://www.slideshare.net/RaquelPau/technical-debt-management-strategies
  • 15. Use debt ceiling to avoid a vicious cycle
  • 16. merciless approach: create a new cleanup column
  • 18. Knowledge Debt Measures: • How much time I need to spent to understand the existing architecture before applying a change? Consequences: • Architecture degradation • Redesign existing frameworks or reinvent the wheel. • A cascade of bugs Solutions: • External Formation • Internal Formation (Stand-ups, Code Review, Pair Programming, Tests)
  • 19. Infrastructure Debt Measures: • How much time I need to spent to deploy a new version? • How much time I need to revert a new version? Consequences: • New versions appears after a long time.. • Super long working days. Solutions: • Define a collaboration workflow and tagging procedure. • Define a repository for software artifacts and Docker images. • Use software (e.g Kubernates, Puppet) to just deploy/revert changes automatically.
  • 20. Architectural Debt Measures: • How much effort is needed to achieve a low coupling and high cohesion? • How much effort is needed to split the development? – Open / Close principle Consequences: • Duplicated code (SonarQube, PMD). • High cyclomatic complexity (SonarQube, PMD). • Broken Windows Theory. Solutions: • Code Review – Check SOLID principles. • Static Code analysis tools (SonarQube, PMD).
  • 21. Architectural Debt A time based approach: Adam Tornhill • Most of your code is not important. Focus on the recent/new features. • Hotspot analysis to prioritize improvements Open-Close semantics validation (using Git). • Complexity Trend analysis to understand how an specific component evolves (using Git).
  • 22. A time based approach: Adam Tornhill • Most of your code is not important. Focus on the recent/new features. • Hotspot analysis to prioritize improvements Open-Close semantics validation (using Git). • Complexity Trend analysis to understand how an specific component evolves (using Git).
  • 23. An estimation approach: ticketmaster https://tech.ticketmaster.com/2015/06/30/what-ticketmaster-is-doing-about-technical-debt/
  • 24. Testing Debt Measures: • How much code coverage do we have? • How much time we wait to run our tests? • How much time do we spent to manually validate the functionality? Consequences: • Bugs (FindBugs) • Low code coverage (SonarQube) • Slow validations / code reviews. Solutions: • BDD or TDD • Continuous Integration tools. • Code Coverage tools. • Static Code Analysis tools (SonarQube, FindBugs) 
 Do not loose time running unrelated tests • Split the project into sub-projects (e.g microservices) as much as possible. • Run integration/application tests from the CI. • You will not receive interruptions for lack of resources.
  • 25. – Joshua Lewis “unit tests are the most, not the foundation”
  • 26. Code Standards Debt Measures: • How much code violates our coding standards? • How much clear are our names? Consequences: • We spend more time understanding code Solutions: • Static Code Analysis tools • Continuous Inspection • There are a lot of static code analysis tools and linters for every programing language. https://www.sonarqube.org/ https://pmd.github.io/ http://checkstyle.sourceforge.net/ 
 • Every day appear more software to fix code style issues, which reduces the effort to have clean code. http://errorprone.info/
  • 28. –Henrik Kniberg, Spotify, Lego “old debt is bad and new debt is good.” http://blog.crisp.se/2013/10/11/henrikkniberg/good-and-bad-technical-debt