What is technical debt? Technical debt is a concept in software development that represents the implicit cost of an implementation/ solution thought only in the now, instead of using a better quality approach that would take more time.
The technical debt can be compared to a financial debt, which, when you do not pay it, will pay interest over time, making it even more difficult to pay it.
In terms of software, the technical debt creates the difficulty of maintaining code, generating even more delays and changes in the final product.
How to fix all technical debt?
We can’t, that’s right! If you think that the solution to your problems is to end all the technical debt of your project, you are wrong. Technical debt is inevitable and, therefore, will always exist, and it is up to us to control it. For example, only with the passage of time, a technical debt is created because the code ends up aging.
If you or your team is struggling to not have technical debt, know that this is bad, and it is called Gold Plating.
Reasons for the emergence of a technical debt
- Deadlines out of reality
- Deficiency of technical knowledge
- Inappropriate technology choice
- Time passing (Yes! 😢)
- Deficiency of an iterative development methodology (without customer feedback and testing)
Types of technical debt
There are 4 types of technical debt, we can classify it as follows:
How to measure technical debt
Although the concept of technical debt is subjective, there are several ways to measure it, namely:
- Code duplication
- Test coverage
- Build fragility
- Commented lines of code
- Cyclomatic complexity
- Code cohesion
How to treat?
Here at ez.devs we use the Kanban methodology. That way, we always put a percentage of tasks for handling technical debt in the week, so we always have something deliverable and handled in the week (or fortnight).
If you work with SCRUM, you can leave some slack points, so that at the end of SPRINT the team can pull some items of technical debt correction.
In the latter case, you can create a SPRINT or a Release with only technical flow corrections. We don’t particularly like this, as there is no real value for the end customer, so it is always good to merge.
Technical debt x Startups
When we talk about startups we are always talking about testing hypotheses, in this way, many companies end up accepting – even too much – the technical debt in order to launch their products as soon as possible on the market. To talk about this, we need to divide startups into two stages:
Right now, the main objective of the startup is to validate its business model, and yes, at this stage it is very important that we launch MVP as soon as possible. Here a little bit of technical debt is worthwhile, as long as it is in the “Conscious and intentional” quadrant, it is very important to decide what will be left aside so that in the near future it can be treated without too many problems. At this point, experts and developers can make a difference.
In this phase it is important to avoid technical debt as much as possible, and even kill some debts from the previous phase. At that moment, problems of performance, usability, architectures will arise from past debts.
The maximum care here is little, because as stated earlier, the more debt we leave, the more difficult it is to maintain the project.
From there, we need to be more demanding in terms of the quality of our code, set standards, do even more tests, everything necessary to ensure a high level of quality.
Is that you? Do you have a code maintenance problem in your project? Can you negotiate people so that your team has time to deal with the technical debt of the project? Tell us here in the comments.