Technical Debt is not a bug
Technical debt is not a bug. Though both are constant companions in product development. Many authors consider them identical and equate the reduction of bugs with the repayment of technical debt. However, this is wrong. It reduces transparency and thus makes inspection and adaptation difficult. This article explains the differences between technical debt and bugs, why they are important and how it affects transparency in product development.
Little Bugs Everywhere
The term “bug” exists much longer than computers, programmers or software developers. Already in the 19th century, errors in mechanical machines were referred to as “bugs” in the English-speaking world. The term is based on the joking notion that small beetles inside the machines were supposed to be responsible for their malfunctions.
Even in the programming and development of computers, the term “debugging” was already used when analyzing errors during the Second World War. The term “bug”, in regard to computers, became popular through an anecdote from Grace Hopper. On September 9, 1947, there was a bug in the Mark II Aiken Relay Calculator. This was ultimately due to a moth in one of the relays. The engineers stuck the moth in the computer’s logbook and described it as the “first actual case of bug being found”. The Smithsonian Institution retains the relevant page today.
These descriptions from the 19th and 20th centuries provide information about what a bug is. A bug is an anomaly that leads to a malfunction or a complete failure. It is a violation of the given requirements. The actual state of the product deviates from the target state.
The ISTQB defines a bug as an error that leads to a defect that can lead to a failure. Here, too, the clear reference to a violation of requirements is understandable. In theory, it is entirely possible to develop software without any bugs. But it turns out that this is practically almost impossible. It can therefore be assumed that almost all software systems contain bugs, even if they do not always have an impact on the user experience.
More About Technical Debt
Technical debt is a metaphor in computer science. It describes the possible consequences of bad technical decisions and implementations. The debts are the efforts that have to be planned in order to reduce or completely eliminate these implementations through refactoring.
There are different types of technical debt. On the one hand, technical debt can be intentionally raised, for example to reach a milestone. For this reason, technical debt is not an anti-pattern because it is always the result of laziness and / or unprofessional practice. On the other hand, technical debt can be incurred by accident, e.g. because there was ignorance of best practices. In a second dimension, a distinction can be made between thoughtful and inconsiderate decisions. This gives the quadrant of technical debt.
Technical debt can take many forms. A lack of infrastructure, insufficient documentation, disregard for coding standards and the use of anti-patterns are just a few of them. Reasons for the incurrence of technical debt can be insufficient quality assurance processes, insufficient technical knowledge, insufficient communication or backfacting. Interestingly, technical debt can also accumulate if none of these points apply. Therefore, in practice there is no product that is free from technical debt.
Technical debt therefore has a direct impact on the maintainability of software, and thus on the expenditure for maintenance and further development of the software. Technical debt is one of the most important factors why milestones in development projects are not reached or not reached in time. Therefore it makes sense to keep the technical debt low at all times.
Technical Debt is not a bug
We have already found that in practice it is (almost) impossible to develop software without errors / bugs. It is also impossible to completely avoid technical debt. So the question is, what is the relationship between bugs and technical debt? In theory, a system can be free from both, technical debt and bugs. In practice, it is typically not. This results in four combinations of technical debt and bugs.
Now let’s look at some examples of the interaction between technical debt and bugs. Let us imagine that we are on the construction site of a house.
An example of a bug without technical debt is an incorrectly installed window. Let’s assume, the window handle is on the outside of the house. This is a bug that can be fixed by correctly installing the window again.
On the contrary, technical debt can be incurred without generating a bug. The roof of the building should be wind- and waterproof. This could be achieved by using a large tarpaulin. The roof would be wind- and waterproof, and therefore the requirement would be fulfilled. Nevertheless, it is obvious that technical debt has been incurred because the tarpaulin will have to be replaced in the long term.
If we combine both cases, we have a building with technical debt (tarpaulin on the roof) and bugs (wrongly installed window). At worst, a bug is due to technical debt. If the roof window keeps falling out because it cannot be attached to the tarpaulin, then this is a bug due to technical debt. The malfunction can only be fixed by reducing the technical debt beforehand.
Increasing Transparency
The difference between technical debt and bugs is essential for the transparency of the developed product. The greatest effort in eliminating bugs often lies in analyzing the root cause of the defect. However, the effort involved in reducing technical debt lies in the refactoring of the architecture concerned.
Viewing and treating technical debt and bugs identically would reduce transparency in many ways. It would no longer be possible to assess the correctness of the product. Likewise, no statement could be made about the amount of the technical debt. This would make inspection and adaptation of the product quality and the measures to be taken more difficult. In a Scrum team, all three pillars of the framework would be violated.
Final Thoughts
Technical debt is not a bug. Both effects differ fundamentally in their causes and effects. Bugs are functional errors that violate product requirements. Technical debt refers to technical mistakes in the sense of poor design and architecture decisions. In practice, both technical debt and bugs can be found in (almost) every software. Ideally, both should always be kept low and eliminated promptly. In order to increase transparency and thus facilitate inspection and adaptation of the product, technical debt and bugs should always be examined, tracked and handled separately.
