top of page
  • Writer's pictureVanessa Leite

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

  1. 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.

  2. 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.

  3. Schedule a day (or a portion of the cycle) to work on technical debts. It is important this becomes a regular practice.

  4. Everyone should work on technical debts. Again, they are a shared problem, so everyone should work on solving them.

  5. “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.

  6. Resolving technical debts can not add more technical debts. It is a moment to do things carefully and consciously.

  7. New development should not, at least, increase the number of warnings, or non-critical errors.

  8. 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

2 views0 comments

Recent Posts

See All

É o fim de uma era. E eu não posso deixar de agradecer às pessoas que seguraram minhas mãos, enxugaram minhas lágrimas, trouxeram sorrisos ao meu rosto e me deram força e serviram de inspiração. Esses

It is the end of an era. And as such, I want to thank everyone who held my hands, dried my tears, brought a smile to my face, and gave me strength and inspiration. These are my Thesis acknowledgments.

Post: Blog2_Post
bottom of page