More Related Content
Similar to Technical debt management strategies (20)
![From Curiosity to ROI — Cost-Benefit Analysis of Agentic Automation [3/6]](https://cdn.slidesharecdn.com/ss_thumbnails/session-3-250903141006-a3917e1a-thumbnail.jpg?width=560&fit=bounds)
Technical debt management strategies
- 2. a little bit about me • Almost 10 years of experience in Java • Research background on software engineering. • Walkmod project leader • Speaker at several occasions • Writer at Java Code Geeks 2 twitter: @raquelpau
- 3. What does technical debt mean? Technical debt (also known as design debt or code debt) is "a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution" 3
- 4. is the technical debt evitable? 4
- 5. The First to market strategy Minimum Viable Product (MVP): Simple functional prototype. If it makes no sense, we through away the code. • Disadvantages: • Our cost is our own time. • We may through away the code. • Advantages: The right product, will get traction, and then investment. 5
- 6. our first formulas.. Productivity = |Features| / unit of time Feature = refactor + test + code + build + review 6
- 7. and as a result.. the code becomes our own specification 7
- 9. But after gaining traction.. Productivity = |Features|+|Bugs| / unit of time Feature = refactor + test + code + build + review 9
- 10. And then... appeared the ROI (Return of Investment) = gross profit – expenses investment technical debt costeconomical benefit of our features 10
- 11. ...How many bugs do we have? I do not know... but the correct question is: can we reduce the number of bugs? 11
- 12. How to manage the tech debt, now? (without stopping new features, of course) Sprint = |Features| + |Bugs| + |Improvements| 12
- 13. 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. 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) 13
- 14. automated quality controls all debt is bad? 14 source: http://blog.crisp.se/2013/10/11/henrikkniberg/good-‐and-‐bad-‐technical-‐debt
- 15. merciless approach: create a new cleanup column 15
- 16. (1) Versions Control (2) Automatic Build (3) Coverage Control (4) Tests for NEW changes (5) Code Style Control for NEW changes (6) Code Review (7) Characterization Tests (8) Refactorings Increase the productivity Fix the leak Merciless approach prioritizing the technical debt 16
- 17. could we become more productive? 17
- 18. technical debt categories • Architectural debt (refactor) – continuous refactoring • Testing debt (test) – continuous integration • Code standards debt (code) – continuous inspection • Infrastructure debt (build) – continuous delivery • Knowledge debt (review) – continuous formation (?) 18
- 19. 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
- 20. 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
- 21. 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
- 22. 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). source: http://www.adamtornhill.com/articles/software-‐revolution/part2/index.html 22
- 25. architectural debt an estimation approach: ticketmaster source: https://tech.ticketmaster.com/author/simontarry76/ 25
- 26. 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 / SonarQube) • Low code coverage (SonarQube) • Slow validations / code reviews. • Solutions: • BDD or TDD • Continuous Integration tools. • Code Coverage tools. • Static Code Analysis tools (SonarQube, FindBugs). 26
- 27. Testing debt unit tests are the most, not the foundation – Joshua Lewis 27
- 28. testing debt 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. 28
- 29. 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 29
- 30. Code Standards debt – checking & fixing • There are a lot of static code analysis tools and linters for every programing language. • Every day appear more software to fix code style issues, which reduces the effort to have clean code. 30 facebook/pffff google/error-‐prone dotnet/roslyn
- 31. Technical debt distribution (an estimation) Architectural Testing Standards Infrastructure Knowledge Interest Rates Distribution 15 % 10 % 30 %5 % 35 % Fixing Cost Distribution Architectural Testing Standards Infrastructure Knowledge 50 %30 % 10 % 5 % 5 % 31
- 32. Now, estimate by yourself.. 1. Each team member scores a unique value for the different technical debt categories on a pre-‐agreed scale (1-‐5) (low debt to high debt) for: • Interest Rate • Fixing Cost 2. Each category is discussed one by one to reach a consensus. 3. Prioritize the ones which reduces more the interest and has the lowest fixing cost. 4. But whatever you decide, if you write code, do characterization tests, first 5. Define a KPI to review it. 1. Have decreased the number of reported bugs per sprint? 2. Have increased the number of features (e.g stories) per sprint? 32
- 33. Debt Category Fixing Cost Interest Rate Final Value Architectural 5 4 4/3 = 1,3 Testing 4 5 5/4 = 1,25 Standards 2 2 2/2 = 1 Infrastructure 3 1 1/3 = 0,33 Knowledge 1 3 3/1 = 3 estimation example 33
- 34. legacy code rocks! movement • Web page http://legacycode.rocks/ • Slack: https://legacycoderocks.slack.com/ • Meetup Group: http://meetup.com/es-‐ES/Legacy-‐Code-‐Rocks-‐ Barcelona/ 34
- 35. conclusions • Two origins: MVP (idea validation) or productivity reasons. • Fix the leak first. Afterwards, increase the productivity. • There are multiple technical debt categories. • To increase productivity, decide what improvements to do for each category, its cost and the current interest. Then, prioritize them. 35
- 36. Thanks for your attention 36