Technical Debt - is a metaphor that is used when we speak about solutions as for architecture, technology and other technical aspects of the project that we put aside for now, but that will have negative influence on project development later. The concept of “dept” is very meaningful here, technical simplifications that are allowed in this context are not optional and they are postponed because of different reasons, but nevertheless they should be worked out later. In other words – project team takes debt, that they will have to pay it back in future.
For the first time this metaphor was used by Ward Cunningham in 1992:
“Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.” ( Ward Cunningham, March 26, 1992, "The WyCash Portfolio Management System")
As you can see, we are talking about fast solutions, when the priority is given to speed rather than quality (technical aspect). Small debt to the quality may speed the development process, but it should be paid back, sometimes by means of complete revision of the technical solutions. In case, the debt is not paid back, it gains interest and developers may become hostages of such “debts”: further product development is blocked by technical problems of the project.
What is considered to be a technical debt:
Temporal or just not optimal solutions as for system architecture may prevent the system from being flexible, scalable and expandable, if not revised in time. Such solutions, when not rebuild for a long time, may become a real burden and require serious refactoring that may cause time delay.
Not flexible, poorly maintained code containing duplication, hard coding, TODO, code without proper documentation is also a technical debt. This is also a development team liability and it requires to be removed in time. Otherwise, it will cause a number of sometimes very serious problems.
Bad or absent documentation can also be considered to be a technical debt. At least, because it can cause such. In case a person faces the project for the first time without proper documentation it is catastrophically difficult for him to choose the right technical solution under the pressure of implementation deadlines. Such project is difficult to maintain, to conduct refactoring. It is also difficult to adopt such a project from other developer - it is easier to write it from scratch.
Good tests are actually a project documentation. They can be used to understand how the system or API of any component or library is used. From this point of view, the absence or insufficient number of tests may be compared with poor documentation with the same consequences (see above).
Poor quality or insufficient system component coverage of tests may cause problems in case of introducing new features and bug fixing. You can not guarantee that the implemented changes did not destroy anything that worked properly before. Thus, correcting / improving the product we can easily add new problems to it.
Technical Debt Origin
There are several reasons when the technical debt may occur:
Usually a customer is far from understanding technical aspects of the system, he is interested in functional solution and the sooner the better. Optimal solutions usually require more time for proper development.
The market also dictates its own conditions. The time of the working product release may be a critical aspect in certain circumstances, as it helps to leave competitors behind and attract potential customers' interest. At the same time, of course, the quality of the technical component becomes secondary issue.
No business process understanding
Lack of understanding of "What is really needed?" leads to the fact that the system is designed, just based on the current understanding of the business processes. Further, during the lifetime of the system "enlightenment" about the misunderstood parts comes to developers and it turns out that everything has to be completely or partially different and development of the system without further redesign is very difficult.
Absence of necessary knowledge
All developers were young and inexperienced at the beginning. This is the reason why young team at the beginning of their work quite naturally will make not the best technical decisions. They will understand it in the process of gaining experience and maturing. In such way with the team growing up the technical debt of the project is accumulated, that should be paid back.
Also it is not good, when there is no tutor for new team members, who can support and help to join the project successfully, to grow professionally and make the right technical decisions .
Problems in communication between developers and customers may lead to the absence of business process understandingwith all following consequences.
Also such kind of problems may occur inside remote team that develops the project, that may cause chaotic obscure architectural solutions, weird code etc. And in its turn it will cause technical debt.
Lack of motivation, bad team spirit, moral depression can lead to procrastination and choice of not optimal technical solutions, which subsequently should be revised.
Also technical debt may occur:
consciously: when developers realize what problems may occur in future as a result of such decision, what should be paid back later, when there is an agreement that some technical aspects should be revised in future;
unconsciously: there is no clear vision as for the future vector of system development or developers don't have enough technical expertise, which is why neither side has any idea of the problems that will appear in the future.
Developers face with technical problems that prevent from successful system development and improvement process: not optimal code, imperfect architectural solutions , which do not allow just to add new functionality without destroying what already exists. The system itself is not so predictable and understandable when there are gaps in the documentation and little quantity of tests. Working with such system is transformed into "rain dancing", constant tightening the screws, inventing “dirty hack”and endless research of "what is meant by this?". Not so many people will enjoy such work.
From business and management point of view outcome of debt is revealed in the fact that support and extension of such system requires much more time. It happens because not optimal or temporary solutions generate a large number of problems, and it is labour consuming
to fix them without breaking something else. Adding new functionality (system extension) becomes a complicated procedure, it often produces a lot of new problems, that makes support of the system more and more difficult.
As the final result, all these problems transform into cost increase for the support and development of the system, as well as lost profit when the solution is slowed down by accumulated technical debt and it doesn't allow to meet market demand for high-quality product with the required functionality in time and competitors occupy target niche .
Technical debt is not taboo, but you should be very careful with it. It is like bank loan: you may take it in case of necessity, but use it very responsibly and pay back as soon as possible. Otherwise, you'll have to pay high interest or even fine.
Anyway, technical debt is transformed into financial equivalent in the form of cost increase for the support and development of the system.
Situation when technical debt occurs may be different:
fast release of the product is required because of market and business demands despite of quality of technical aspect of such solutions;
there is a young team on the stage of its development and professional maturing that can't make right optimal decisions;
there are problems in communication between members of the remote team, that works on the project or between customer and developers;
team receives for support and further development a project with poor documentation, possibly with great technical debt already;
But despite of situation, developers should try to avoid taking unconscious technical debt, plan its removal and not to postpone it for a long time. Technical debt is like snowball, it grows very quickly and the longer you don't pay it back, the more difficult and expensive becomes system support and development.
Have you ever come across such a sitiuation that you have to choose - to finish project quickly or to make it qualitatively? What do you think is better?