Technical debts - how to pay it off
Technical Debts
Technical debt is the result of prioritizing speedy delivery instead of good code. It encompasses bugs, legacy code, and even missing documentation.
Technical debts are not bad per se. However, the accumulation of technical debts can lead to poor-quality software in the long run.
It is important to get technical debt under control by recognizing its existence and promoting operations to tackle them.
Types
Technical debts are often classified using Martin Fowler's four quadrants: reckless, prudent, deliberate, and inadvertent.
Prudent and deliberate: a conscious decision of creating technical debt, often when the benefits of a quick delivery are higher than the risk of producing code without following the complete pipeline. We do it now, and quickly, and deal with the consequences later.
Reckless and deliberate: also a conscious decision: we know what we need to do, but we feel there's no time to do it right. The difference between being prudent and reckless is to feel pressured to not do the right thing and actively decide to not follow the process.
Prudent and inadvertent: not a conscious decision of creating technical debt. We believe we are doing the best possible, but we learn while producing code. It is not uncommon that after implementing a feature we get knowledge and insights about a better solution for the problem.
Reckless and inadvertent: also not a conscious decision: we don't even know the mistakes we are making. The team believes to be doing the best possible, but they don't have enough knowledge to produce the required software. The difference between being prudent and reckless is about awareness of how much information we have before starting to develop software.
Addressing technical debts
We can ignore technical debts for a while, but sooner or later the issues will spread and affect other areas of the production and development process.
The two main approaches to dealing with technical debts are to keep a tracking system and add technical debts to our to-do lists.
Keeping a tech debt list is a good way to see how much we pay off our debts. Any technical debt hanging there for more than 3 months, for instance, should be treated critically.
If we don't track our debts, it is harder to see they exist.
https://www.stepsize.com/blog/complete-guide-to-technical-debt
There are two common ways to pay off the technical debts: either by considering them as issues that are part of the development cycle, or tackling them on a specific day, as a tech debt day.
In any case, addressing technical debts is not the most exciting task.
It is really important the team sees the value of doing it. And more, that they get to define priorities regarding the debts to be worked on.
Another important factor is: we shouldn't add more technical debts while fixing some.
Addressing technical debts should follow the complete pipeline of development.
Direct steps
Identify technical debts: the whole team has the power to add issues as technical debts. We should do so as soon as we identify them. Don't keep it for yourself. Technical debt is a shared problem.
Not all technical debts are code related. If a team member feels there’s not enough knowledge/information to pursue a development this needs to be brought up as well.
Schedule a day (or a portion of the cycle) to work on technical debts. It is important this becomes a regular practice.
Everyone should work on technical debts. Again, they are a shared problem, so everyone should work on solving them.
“Oh, but I do my code really well, and I shouldn't fix other’s people issues”: we are a team, if you believe someone is not delivering code as they should (or, as you are) then it is part of your job to share knowledge and talk to people about how to do development.
Resolving technical debts can not add more technical debts. It is a moment to do things carefully and consciously.
New development should not, at least, increase the number of warnings, or non-critical errors.
automatic tracking of this is a way to pay attention to new reckless debts.
Tech Debt Day:
Planning and prioritization of the issues
ideally, the issues are already defined: developers create issues as they arise
Evaluation of metrics (based on CI pipeline)
number of warnings
number of errors
number of deprecated tests
number of unlisted/not working tutorials
Paying debt
Re-evaluation of metrics