It's not technical debt, just a bad code

In recent years, there has been a lot of talk in the development community about technical debt. The problem is that it's a term that is too often used as an easy excuse to justify bad work. This article what and what is not a technical, debt, and what should you do about it.

What is technical debt?

The term technical debt was made by Ward Cunningham to portray the specialized compromises that people involved with software engineering must make to meet due dates and client desires. In brief, problematic short-term plans may have to be be pplied since the program does not permit for long-term plans. As a simple illustration, the beginning design of your site may ought to be frame-based since you are running of time to properly setup an AJAX system.

Financial debt, a metaphor

When you take out one or more bank loans, you go into debt. If we take out too many, we are in over-indebtedness and this becomes dangerous for our finances. In any case, these credits must be repaid, generally with interests. This whole system is clear from the start, there are no surprises.

📝The technical debt, by analogy, is the taking of a technical shortcut, being aware that one day it will have to be paid back. If you take too many shortcuts, it becomes dangerous for the code base. So far we can easily follow the analogy.

Do we have a choice?

In both cases, this debt is not unhealthy. Just as you can take out a loan to make the right expenditure at the right time, you can take out technical debt to deliver a feature with the right Time To Market. It's even a good thing, as this decision can generate cash more quickly and offer the possibility of continuing to evolve by paying the interest on this technical debt.

The important concept here is choice. Just as you can't get into financial debt without signing a credit agreement, you can't accidentally get into technical debt either. You have to want it.

Without ever taking out financial credit, you can find yourself in the red at the bank. This is not indebtedness but a bad management of one's money for various reasons, whether personal (badly distributed expenses, ...) or external (insufficient income, ...).

In the same way, a code base can be rotten by a bad management, either personal (lack of competences, motivation, sloppy work...) or external (bad quality process, harmful management, unrealistic deadlines...) 😤

This is often the case, and communication problems are one of the first causes of techincal debt, even before technical incompetence.

Like financial management, code management and the environment in which it is produced are things that need attention and time. But not giving yourself the means to do things right (or giving those means to the teams) is not technical debt, it's just producing bad code.

Properly paying your technical debt's interest

Technical debt may be essential, but if you want to be able to pay it later on, it should better be clean! If you are going to implement a frontend, and instead of using AJAX, you decided to opt for a frame. At that point make beyond any doubt that the developer is a craftmanship. Make beyond any doubt the plan is well adjusted, and the code is clean.

If that frame gets poorly implemented, you’ll never be able to supplant it with an AJAX system. The mess will obstruct your advance forever. 😢😢

Conclusion

Due to new technologies and changing approaches in software development, technical debts cannot be entirely excluded. They are even tolerated if they allow the rapid and regular release of programs and applications without tying teams to projects on a long-term basis. However, there are preventive measures that can be taken to avoid or reduce the formation and growth of technical debt:

• Use standardized code rework and quality management processes
• Use up-to-date error detection and analysis tools
• Maintain technical knowledge through continuous training or define team composition according to qualifications
• Design the code in a clear way by dividing it into classes and using understandable methods and write the code in a way that is readable for new programmers joining the project or for external programmers
• Assign clear responsibilities and allocating tasks between teams to avoid duplication, redundancy and counterproductive work steps
• Keep the IT architecture up to date through constant monitoring, analysis and quality control.