What is technical debt?

Question

Technical debt is the sum of some types of backlog in your project that can prevent the evolution of your project. However, this concept is much more comprehensive than that, and I would like to have the following questions answered to help you better understand the concept.

What exactly does this debt refer to? Why does it prevent the evolution of the development of the project? There is an acceptable rate of this debt within the project?

Answer 1

We can resort to wikipedia article to have an acceptable definition.

Roughly speaking, all the activities inherent in development, but not directly defined functionalities in the project, are left behind unconsciously or consciously uncontrolled by the developer or development team, regardless of the team’s planning. It’s something everyone knows exists, but it’s hard to identify where she is. In practice we are always in technical debt when we begin to execute a project. You can minimize its effects but you can’t fight it completely. There are always activities that would benefit the project and that are forgotten or relegated due to existing restrictions.

Some say that an agile methodology helps to combat the existence of these debts, others say that in fact it is responsible for the increase of these debts. My experience is that Agile usually helps to identify these debts, which is good, but also helps to create them. In the name of methodology, the result ends up being damaged.

Some say that the attempt to avoid these debts causes delays in the projects. Others say that leaving debts cause larger delays over time because they entail extra work that would not be needed otherwise.

One thing is certain, however much a methodology can help if there is no will and resources the debt will always increase. And if we regard debt as inevitable, we cannot regard it as something inherently harmful. Software projects are complicated and the search for perfection can even help identify technical debts but can generate new ones. Finding the balance between result and overall quality is always very complicated.

The most common debts involve activities that developers do not like to do and that are not mandatory to get a result (good or bad). Are the activities:

• Documentation
• Test writing
• Resolution of warnings and other pending items indicated by the compiler or static analysis tools
• Bugs difficult or boring that nobody wants to take responsibility for
• Codes that need a new iteration to solve any problem, notably where there are comments like "TODO" and "TOFIX" or some technique to mark as "Not implemented Yet".

These debts occur by ignorance of what to do, disregard for activity or lack of conditions to perform the tasks, either due to lack of resources (time, money, trained people, etc.), or due to a legacy situation that makes it difficult to perform (lack of understanding and wrong decisions in management or architecture).

It has long been known that managing these debts so they don’t get out of hand is key to avoiding bigger problems and creating accidental complexity. This management goes through not allowing debts to accumulate. The sum of debts can cause new debts, just like in financial debts.

What technical debt probably is not: consciously leave functionalities to be implemented later if they do not need to be implemented now and it is known that there will be no problems do later. We cannot consider as technical debts any planning that deliberately indicates the creation of new functionalities at later times. Which is different from delays caused by any reason, including wrong planning (an example where trying to better organize causes a technical debt).

Also not the mess of the project.

Obviously what is left for later cannot prevent the normal progress of the project. Debt is what prevents progress in good conditions. And it is very easy to find that something is not preventing anything and actually being. It generates interest. The debt gets bigger just because there is debt and it will be harder to pay. It is very difficult to determine when a debt can be worth the effort to have it.

I see a certain schizophrenia between this and Agile or similar methodologies. Many proponents of Agile preach not having technical debts. But how can I do this with such small interactions? I may be wrong, but everything I’ve seen, technical debt can only be combated in larger cycles. In the background methodologies contrary to Agile seem to exist for this very, ensure that nothing is left behind. Some will say that the understanding is not quite this. But then comes what I always say, if it’s too complicated to understand and do it right, it’s probably not the best thing to do next. If Agile were so good, people would get the way to use it more easily. This is corroborated by what Martin Fowler says. Delivering fast and delivering right don’t go together. Some people already accept that in the background it is very rare to see someone actually applying Agile, they apply their version of what is Agile.

It may seem confusing what it is. These terms and methodologies are just like that. Some few privileged people fully understand its real meaning, the exact point of how it should be applied.

Anyway, we should not fear technical debts, we should know that they exist and the best way to manage them is the hardest part, thank goodness we did not ask this :).

I do not know what measures determine what is acceptable, I think it is unlikely that there is a relevant way to define this. It’s like determining the progress of a project by the amount of lines of code in a project.

Measuring Programming Progress by Lines of code is like Measuring Aircraft building Progress by Weight -- It is said to have been said by Bill Gates

The expression is credited to Ward Cunningham.