Understand what is technical debt? and how to deal with it
This workshop is a 2 hours workshop you can run in your team during a retrospective or ad-hoc to align on this concept.
This workshop is designed to be accessible to technical and non technical people as well
Here is the facilitation support :
Connection : 3 words
Ask to the participants :
1.
In solo : Write down three words that you associate to the expression "Technical debt"
2.
In pair :
Share your thoughts
Agree on a definition
3.
All together :
Share your thoughts
Agree on a definition
Concepts
What is Technical debt ?
“Some problems with code are like financial debt. It's OK to borrow against the future, as long as you pay it off.” - Ward Cunningham
Technical debt describes what results when development teams take actions to expedite the delivery of a piece of functionality or a project which later needs to be refactored. In other words, it’s the result of prioritizing speedy delivery over perfect code.
Difference between Bad code & Technical debt
"Just because some code is bad doesn't mean it's technical debt. It's not technical debt unless we have to pay interest on it, and interest rate is a function of time" - Adam Tornhill in Software Design X-Rays
Symptoms
Accumulate bugs
Add a new functionality will cost a lot of money : reduced velocity
How do we create this debt ?
"We don’t have time!"
One thing we hear the most in teams is the lack of time as an explanation of technical debt creation :
“No time to rethink the design of this class, just keep adding new stuff to it!”
“I didn’t have time to write the unit tests”
No time to think about how someone else will fix or extend the code
…
Other causes
Poor Conception : No time for architecture and design.
Poor Business understanding : It is impossible to design something you do not understand...
Poor Scheduling / Underestimating : No testing effort in estimations.
Bad Development Practices : Development team needs to have a set of practices and conventions so that there is a little or no significant difference in design and implementation from feature to feature.
Outdated Technology : As technology evolves, software standards become higher every day : No technology watch, innovation time
No team rules / conventions
Only Michel knows this piece of code, no one else can update it (SPOF
…
The technical debt creation can be deliberate or inadvertent. That's what Martin Fowler explains with the Technical Debt Quadrant :
Bad naming : Source code is not understandable by anyone.
Low/No Test Coverage : Tests ensure that each part of the code is behaving the intended way.
Code duplication
Lack of Modularity : Some code sometimes serves different business logic. The more codes developers write, the more lack of modularity can bottleneck.
Code Complexity : Complexity can be measured in several different ways, but it measures the dependence and path length to perform an operation. A long path leads to complex code.
No automation : Deployments and tests are done manually.
Concrete practice : Dice of debt
Dice of debt is a serious game that demonstrates the importance of managing technical debt. It has been documented on the agile alliance website here : https://www.agilealliance.org/dice-of-debt-game/
We must build quality in by using great development practices
How to manage it ?
Ask questions to the participants / small technical retrospective :
Which examples of technical debt do you identify i our code base ?
How do you materialize it in the backlog ?
How can we improve the management of the technical debt ?
How could we reduce it ?
A concrete action that we could implement tomorrow
Measure things
We can easily measure things that can help us quantify our technical debt :
Functionalities : Measure the performance of the system for each period of time (iterations) by measuring the number of functionalities (User stories) done / delivered.
Bugs : Number of "stuff" to fix in the code : bugs, fixes.
Technical debt : Number of refactoring or technical improvements identified by the team.
The definition of this measure can differ from one team to another and it’s fine. The only things is that this definition must be constant for the team.
Use static code analysis tool
Tools like Sonar can give an idea on the health of your code base (some trends to follow). It calculates technical debt indicator :
Make the debt visible
Create items in a backlog for everything that is identified and monitored by the team as a subject for refactoring or technical improvement.
Invest
Dedicate time to technical debt reduction and prevention.
Technical retrospective : Focus on the technical/architectural improvement