Tips and tricks to tackle technical debt
Technical debt is something common for all software development teams. A good development team is not a team without technical debt. It is almost impossible for a team, as good as it is, not to have any debt at all! We all face the same issues of tight timelines that sometimes lead to some compromises. A good development team is a team that minimizes and manages its technical debt.
That being said, this paper does not claim to be “the” way to properly minimize and manage technical debt. You may have methods already in place that bring you this mitigation and management result.
In this article, I will bring my opinions based on my professional experiences and I will identify everything through four sections:
- Concept definition
- Identification and estimation
- Management and prioritization
- Reducing your debt
So what is technical debt, according to our friend Ward Cunningham ?
“Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with refactoring . The danger occurs when the debt is not repaid. Every minute spent on code that is not quite right for the programming task of the moment counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unfactored implementation, object-oriented or otherwise.”
Source: Agile Alliance
Technical debt can be created for a variety of reasons:
The important thing is that if you make the decision to create debt, it must be made as a team and justified to Product Owner (and the customer). This debt must then be documented somewhere where it can be visible to all.
Identification and estimation
Because the technical debt is stored in a location accessible to all, all members are responsible for identifying and estimating it. Not every technical debt is created as equal. Each has a higher or lower “interest rate.”
It is up to the team to determine what is important or not and to face the music (#transparency) by explaining to the stakeholders the short, medium or long-term impacts.
Here is a list of criteria that can help prioritize technical debt:
|Technical Debt item attribute||Detail, Rational|
|Type of impact||Which activities and, abilities|
will it hurt?
|Amount of impact||How much will it hurt? Is the potential negative impact on the business limited or ….very high?|
|Duration and periodicity of the impact||Will the impact happen once, or will it recur?|
|Timing of the impact||Will the impact be perceived very soon (i.e. when I will need to achieve a good unit test coverage), or later, after delivery?|
|The age of the Technical Debt item||Is it “legacy TD,” or did the team add it during the last sprint?|
|Is it intentional or not?||Involuntary TD may trigger coaching and training for team members.|
This will help to plan and prioritize repayment activities.
|Dependencies with other Technical|
|Is the Technical Debt item included within the impact scope of another debt item?|
I like to use two metrics, which I would call “homemade,” to identify a technical debt:
Tales of the Bible sacred words
If I or one of my colleagues say too many bad words every time you touch a particular section of an application, it may mean that a technical debt is needed to improve the maintenance of that portion.
Well, some colleagues have easier biblical tales than others. Whether someone uses a foreach loop instead of a LINQ statement, or else the variables do not respect the case (capital versus tiny) … good luck justifying the importance of this debt to the product manager! The real solution here, to be listed as technical debt, is to add a linter to the project. It is then possible to ensure that the tool is run in continuous integration (CI).
It is also important to know that the size of a technical debt is also influenced by the life cycle of the project (in development versus maintenance).
Third strike, you’re out!
For those who know my love of baseball, if you’re at the third bug for the same code section (class, module, etc.) it’s important to create a technical debt. It is also suggested to increase the unit tests of this section and to ensure that all three bugs are associated with a unit test. I also tend to insert the bug number in the test comments to justify its existence!
Management and priorisation
The Agile Alliance recommends several techniques to ensure sound management and prioritization of technical debt in this document.
This ranges from dedicating full Sprints to technical debt or just a portion of the team’s velocity. Depending on the size of the workload.
In the context of projects where I have an influence, I tend to integrate technical debt directly into the product backlog. To identify technical debt, you can use either a prefix in the title, a tag or another type of task with its own iconography (e.g., creating a custom workitem type with Azure DevOps). I believe that each technical debt should be estimated in time, as part of a tasking session, and not in story points to prevent influencing the velocity upwards (no double-dipping!).
Reducing your debt
There is a plethora of techniques to reduce technical debt or the chances of creating new technical debt. Here are some examples:
- Have a Definition of Done (avoid surprises!)
- Have a Definition of Ready (make sure a story is complete before estimating it)
- Have syntactic code analysis (SonarCloud, linter, Roslyn Analyzers)
- Code review (via a pull request mechanism)
- Code coverage via test execution
- Make sure you are up to date with the versions used
- Technical training
- Agile architecture (i.e. validate before, during and after)
- Automation (to reduce human handling errors)
- Boy scout rule
All these measures are important! In my opinion, people do not have fun creating technical debt knowingly. They always do their best with the knowledge they have at that time within the time given. I love the boy scout rule, that is, when you add a feature, you must leave the camp, in this case the code, as clean or if not cleaner than on arrival.
Be careful here not to embark on a complete rewrite by tackling an oversized piece of software. Ask your team for advice before embarking on this kind of adventure! Try asking yourself what the short, medium and long-term benefit will be.
There is no miracle recipe, just lots of techniques, common sense, discussions and far too many articles on the subject (see references).