When something inside our software is not built in the best possible way, could be improved, still has pending work, or causes an error, we often call it technical debt. But is that always true? Where are the limits of the term?
Definition
Within Agile, we call technical debt the act of taking time away from current development. That work is postponed and there is a commitment to address it later, with the intention of delivering value sooner.
Several important ideas can be extracted from that definition.
Taking time away from current development
First, there must be awareness that a feature or some code should be done so that the technical solution is complete and works within the agreed standards. When that is known, but business needs require shipping functionality earlier, we look for a way to cut those additional edges temporarily.
It is postponed and a commitment is made
Once we are aware of it, and after deciding which technical pieces can stay out because they do not have an immediate business impact, we can agree to “borrow time from the future”. Instead of doing it right now, it will be handled later, but with an explicit commitment that it will be done. That means it is not really a cut, but a time shift of an action.
Delivering value earlier
When we talk about delivering value earlier, that should not be a development-only decision. Business has a need that must be satisfied urgently. This will not always happen, but when it does, we should remember that we are building a product, and without a product there is no business. If the product is expected to reach the desired quality, that debt must be addressed because it is one of the required conditions.
Technical debt must be agreed upon by business and the development team. If both sides do not have visibility into it, this replanning should not happen.
What is not technical debt?
If we understand the concept correctly, it should be clear that if we were not able to detect this debt, then it is something else: bad software, bugs, or an undefined feature. It is not debt, because it was never identified and no commitment was made by both sides.
Technical debt can originate from many causes: lack of technical knowledge, missing requirements, or poor communication. But it must always be detected and negotiated. Otherwise, it is simply poor practice.
Conclusion
As software professionals, we must assume that we will face technical debt every day for different reasons: technical uncertainty, delivery pressure, expectations, or unexpected complexity. It can become frustrating if it is not handled correctly. To avoid reaching that point, several factors matter:
- Document the debt: you can collect this information in a
tech-debt.mdfile inside the project and link it from yourREADME.md. Avoiding surprises matters. - Be transparent: once it is known, it is easier to address. In many cases, if managers know about it, the debt may never be created because expectations can be renegotiated with the business side.
- Do not let it pile up: cleaning a bit every day is easier than cleaning once every four months. Accumulated work is more stressful.
Let’s avoid this:
And move toward this:
