Technical debt is one of the immense disappointments and demotivators of the development teams. As a rule, it is not challenging for teams to assemble technical debt examples in their codebase. Shortcuts in the code, low-quality code, temporary workarounds, and other hacks can deliver short-term solutions but guarantee long-term pain. Developer teams are often intensely aware of technical debt accumulation but feel weak and unable to explain why technical debt should be prioritized. Instead, they think that “business is constantly adding more features than stabilizing the base.”
We decided to present our own perspective on technical debt in terms of many years of experience working with various development teams. We think the article will be interesting for both managers and engineers of different levels of “seniority.” Perhaps the material will be useful to other professionals; at least, we thought it was universally helpful.
Short description
Technical debt describes the results when development teams take steps to facilitate the provision of part of a functional or project that subsequently needs to be reconstructed. In other words, it is the result of the priority of fast delivery over the perfect code. The incompetence of managers or engineers, leading to increased technical debt, can be conscious or unconscious. Debt is sometimes created by a specialist purposefully, under the strict guidance of a manager or independently. Covering tech debt takes resources — money, time, and knowledge.
Categories
To make the context clearer, we will immediately bring up several categories for technical debt.
Security is a “filter” that allows an application or system to respond in a given way to interactions from the outside world.
Performance is the execution of a use case at the lowest possible cost of computing power.
Integration categories: how exactly the interaction of application components is built.
Custom categories: since any application’s task is to improve a person’s life, it should be convenient to use.
Tech debt and point of view
You need to choose a point from which to view technical debt. This is a significant point, as the opinions of team members may differ. For example, the software being developed will run exclusively in a physically isolated system. This means that it must be viewed from the perspective of this system and put the system’s security needs at the forefront.
It is likely much more important to analyze performance and usability issues. Probably everyone remembers the slow and uncomfortable multimedia systems of cars of the 2010s. For its time, it was gorgeous know-how, but today it is an inconvenient and annoying solution.
Applications that work with sensitive data in deep integrations and interoperate across environments and systems need to be secure first.
The technical aspect of the question
Any technical problem can be solved in an infinite number of ways. The more experience a developer has, the better he thinks ahead, the more elegant solution he gets in a minimum amount of time.
The result is fewer “nested-square” solutions. Moreover, an experienced engineer can teach a less experienced one, explain how to improve a particular solution and point out potential problems.
Every “nested-square” solution is a potential danger in the future: memory leak, incorrect type conversion, data loss, and so on. However, it should be borne in mind that potential problems do not always become a reality. They can go through the entire life of the product and never show up.
The manager aspect of the question
The processes in which people work affect them directly — starting from the low quality of the described tasks and ending with the pressure and stress before each release. If technicians are responsible for the product, then managers are accountable for the comfort of the engineers. The low level of competence and involvement of the manager in the product development difficulties, the desire to exclusively please the sponsor or investor is likely to lead to problems in the future and require “expensive treatment.”
You need to understand that an unhealthy atmosphere within the team affects all developers, which means it is a multiplier for problems. Due to the inability or unwillingness to negotiate, poor-quality solutions or even “bookmarks” (unofficial backdoor) may appear in the system. Consequently, the manager must determine the level of comfort while keeping the nose downwind to mitigate or resolve the problems that have arisen promptly.
Many of you have probably come across a situation where a manager avoids solving problems and, at best, arranges a public rally, where the heat of passions only provokes opponents and brings them to complete exhaustion. The problem remained but went under the rug because everyone was tired. Until next time. From the manager’s point of view, if the problem is no longer discussed, it has been resolved.
In our experience, a good manager in such discussions should create a plan for solving the problem and not solve it on his own. If the teams disagree, then facilitation practices can help the manager; delegation to the Scrum Master is also an option.
How to solve the problem of debt
In a rapidly changing world, it is impossible to create a perfect product. The team must accept that there are no excellent products; there are under-analyzed ones. No matter how smart and talented team members are, a problem can always arise. An illustrative example is the Challenger shuttle disaster (when the space shuttle collapsed due to the explosion of the external fuel tank in the 73rd second of the flight, which led to the death of all seven crew members).
The debt resolution process is primarily about registering all existing problems. Potential problems also need to be noticed, even the most incredible ones. This will help you find elegant solutions.
To correctly record this debt, it is better to break it down into sources of occurrence, for example:
- versions of libraries and applications used;
- safety problems;
- architecture errors;
- potential places for code improvement;
- warnings from compilers, interpreters and runtime platforms.
Simultaneously, this should not be a formal process but a working tool of the team. Debt servicing and administration look like a chore, but something can be automated. For example, version checking can be automated by monitoring scripts, while reading Release Notes / Change log / CVE (Common Vulnerabilities and Exposures) requires a separate specialist time. The team chooses this engineer, and management must agree on the costs of such work.
When creating tasks for the normal development process, it is worth focusing on the “debt book.” Debt closure may look like a defect or a feature: depending on how the team will agree or how the customer wants. Perhaps the amount of debt is essential to product sales.
Technical debt requires frequent communication. This can be part of the transmission during backlog grooming or done in a separate process. The most important thing is to review the debt and clarify the seriousness of the problems regularly. After all, this is also part of the product, and it already works.
What about tops?
In the world of commodity-money relations, wherever there is money, there is responsibility. And the inability to fulfill the assumed obligations, risks, and obvious problems should be identified and discussed. The Debt Book is not only a team tool. This is the reverse side of the product’s medal: on the one hand, it’s a success; on the other, it is a colossus with feet of clay.
This document should be made available to sponsors, investors, and all executives — both those who pay and those responsible. In what format to provide information — a question for the manager. After all, priorities for development can come down from the top. It means customers should be informed about what should be covered in the product, except for their desires. In any case, a two-way exchange of product information is always useful.
Risks
The primary and significant risk is to slide into legacy and lose product expertise. Few people want to poke around in incomprehensible code, implicit relationships and disassemble the past’s best practices. Usually, problems start with finance, which is expressed in the ratio of new features to defects.
When support begins to prevail, the people who created the product begin to leave, as do those who supported the processes. With specialists’ departure, especially key ones, no one often wants to take on new responsibility. Or no one understands what and how best to do.
Over time, this debt book becomes an artifact of the past. And since no one works with it, it may seem that the product is perfect and all debts have been closed. For the upper classes, this can be a signal that the product has found perfection. And in fact, the people who are now on the project do not deal with technical debt but only cover sudden needs.
Accumulated technical debt and managerial blindness lead to the emergence of competitors in the market, confrontation, and even defeat. A canonical example of an unsolved technical debt problem is the war of currents. In short, Thomas Edison could not solve the problem of power transmission over long distances. And George Westinghouse could, despite Edison’s black PR.
Summary
There is no recipe for how to do it well. But you can create a resume that will help with this and certainly will not harmful. If you are a fan of your product and want to develop it, pay attention to the recommendations below, but remember, they are not the only correct ones (you can always adjust by creating your own):
- Make a convenient tool to keep track of the versions in use and the versions of third-party products presented in your solution.
- Track security incidents for your product and the products you use. Try to order an independent security audit.
- Divide clearly the areas of responsibility: who is responsible for administering the problem and for solving it. A clear boundary will avoid unnecessary work.
- Discuss the work with the technical debt, analyze the resource costs for this.
- Agree on the debt book format, how it looks to engineers, managers, and customers, and sponsors.
- The manager must be able to reasonably conduct a dialogue on the technical debt with both the performers and the customer.
- Discuss debts regularly, assess the risks and their severity. Remember: a prophylactic examination is better than surgery.
