Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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
What does technical debt mean?
Technical debt (also known as design debt or code debt) is"a concept in programming that reflects the extradevelopment work that arises when code that is easy toimplement in the short run is used instead of applying thebest overall solution"
3
is the technical debt evitable?
4
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
our first formulas..
Productivity = |Features| / unit of time
Feature = refactor + test + code + build + review
6
and as a result..
the code becomes our own specification
7
our common excuses..
8
But after gaining traction..
Productivity = |Features|+|Bugs| / unit of time
Feature = refactor + test + code + build + review
9
And then... appeared the
ROI (Return of Investment) =
gross profit – expensesinvestment
technical debt costeconomical benefit of our features
10
...How many bugs do we have?
I do not know... but the correct question is:can we reduce the number of bugs?
11
How to manage the tech debt, now?
(without stopping new features, of course)
Sprint = |Features| + |Bugs| + |Improvements|
12
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.eMerciless approach)
13
automated quality controlsall debt is bad?
14
source: http://blog.crisp.se/2013/10/11/henrikkniberg/good-‐and-‐bad-‐technical-‐debt
merciless approach: create a new cleanupcolumn
15
(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
could we become more productive?
17
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
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).
source: http://www.adamtornhill.com/articles/software-‐revolution/part2/index.html22
hotspot analysis
23
complexity trend
24
architectural debt an estimation approach: ticketmaster
source: https://tech.ticketmaster.com/author/simontarry76/25
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
Testing debtunit tests are the most, not the foundation –Joshua Lewis
27
testing debtdo 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
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
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
Technical debt distribution (an estimation)
Architectural Testing Standards Infrastructure Knowledge
Interest Rates Distribution15 % 10 % 30 %5 % 35 %
Fixing Cost Distribution
Architectural Testing Standards Infrastructure Knowledge
50 %30 % 10 % 5 % 5 %
31
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,
first5. 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
Debt Category Fixing Cost Interest Rate
Final Value
Architectural 5 4 4/3 = 1,3Testing 4 5 5/4 = 1,25Standards 2 2 2/2 = 1Infrastructure 3 1 1/3 = 0,33Knowledge 1 3 3/1 = 3
estimation example
33
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
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
Thanks for your attention
36
Related Documents
