What is technical debt? Here’s what you need to know!

Sometimes technical debt is a small, sometimes a big oversight. But the longer we delay getting things right, the greater the risk that there will be an explosion that will leave our project or our company covered in a layer of foul-smelling excrement. Technological debt (or technical debt) is in fact like debt – the longer we postpone payment, the more interest we have to pay.

Technical debt, technological debt exists in every IT project. In other forms, this phenomenon appears everywhere. In our home, when a corner begins to exist where disorder grows – as in the proverbial sweeping under the rug – it grows, it grows, until at some point we realize that the whole apartment is a mess. In our bodies, when a few cells get out of control and start multiplying, and years later it turns out that the doctor diagnoses cancer. As well as in business – for example, when an elderly employee who has been involved in part of some important business process for years retires or dies, and with him or her the knowledge and ability to perform tasks that turn out to be crucial is lost. And suddenly the whole company is in trouble. Technology debt is the seed of chaos. The responsibility of developers and IT managers is to control it, to keep it from growing too large. Otherwise, if we just let it sprout, let it grow roots, technology debt will destroy us – our work, our company, our lives.

Technical debt is something that employees in all IT projects face, from those in management positions to developers at the bottom of the employee hierarchy. Although the term technical debt was defined nearly a quarter of a century ago, many people don’t realize that they encounter it every day. Due to a lack of knowledge about the existence of debt, there is also a lack of information about how to safely manage it, how to repay it, and whether such repayment is always necessary and expedient. Most importantly, the lack of identification of debt makes employees unaware of the risks it poses, and often the dangers of technical debt are disastrous. 

Technical debt is usually closely related to the planning stage of project work, especially in the context of refactoring. This means that the restructuring of existing code (refactoring) is required as part of the development process.  In other words, these fixes are not just the result of poorly written code, but also occur based on a later understanding of the problem or additional requirements introduced by the customer. Frequent refactoring is one of the more effective ways to address this issue. Considering the aforementioned facts, already during the project planning it is worth to think about the code refactoring.  You should pay particular attention to the frequency of refactorings performed so far and consider what is the main reason for the small number of refactorings. Often the reason is a poorly planned budget and cost reduction in the form of abandoning refactoring. Another important factor negatively influencing the quality of refactorings is a rush, resulting from time pressure during functionality implementation. When the estimation of workload for a particular stage of the project is lowered, it is logical that something should be given up. A quite common and wrongly used practice is to abandon refactoring. 

The causes of technical debt are multiple, and the impact of debt on the project is also diverse. Just as in the financial world, in the technical area we have different approaches to debt. Based on the way it is created, we can divide technical debt into three main types:

1. Unavoidable technical debt – this is a type of technical debt whose growth is beyond our control. It is often associated with a changing market, changing customer requirements or the tools used to develop our software.
2. Unintentional (reckless) technical debt – is a type of technical debt that is caused by ignorance, inexperience or carelessness.
3. Strategic technical debt incurred knowingly to achieve short-term goals

Causes of technical debt:

Business pressure – this phenomenon occurs when the product has to be finished earlier than initially intended for various reasons, or software development is delayed for various reasons and it is not possible to postpone the release date. 

Problems with implementation and integration. The problem occurs especially in case of non-standard configurations of customer environments and integration with third party products. Due to the variety of software on the market and the ways it can be configured, this problem is quite common.

Communication problems. These difficulties may consist of communication failures between the software development team and people responsible for business goals, as well as lack of information flow within the team. It is also necessary to add that it happens that the software development unit has so much domain knowledge that it is not able to transfer this knowledge to others in a short time. As a last resort, he/she provides information in a perfunctory manner, which results in dissatisfaction of the interested party, i.e. an employee struggling again with a problem that he/she has already encountered and solved before

Architectural problems. Architectural errors have serious influence on application development, often making it impossible to extend the software without time-consuming changes preceded by another analysis. 

Insufficiently performed analysis. It mainly concerns requirements analysis.  For example, not performing the analysis of non-functional requirements influences not proper decisions concerning the architecture of developed systems. 

Simultaneous development of many versions of software. Developing many versions at the same time leads to numerous inconsistencies that are difficult to manage. 

Insufficient code refactoring. Lack of the habit of constant correction of small imperfections in the code causes defects to accumulate, and what was initially a minor problem, makes the code unreadable, less optimal, and subsequent modifications become difficult to implement and time-consuming. 

Insufficient automated testing. Automatic testing, performed on an ongoing basis along with the delivery of subsequent versions of code to the repository, allows you to get quick results on the correctness of the changes made

Too many manual tests. Manual testing should be limited to a minimum, as it often depends on the momentary disposition and competence of the tester. 

Uncorrected bugs. Bugs that are not corrected may lead to exposure of further irregularities during coding and testing of the application. 

Wrongly chosen technology. Choosing a technology dedicated to a specific solution is an important factor influencing project success.

Lack of experience connected with a particular technology. Lack of experience increases the susceptibility to making trivial mistakes, which at the same time may be fatal. An example may be a programmer who started using a new programming language. During the initial period of working with a new technology, he may not be fully aware of all its attributes and differences from the tool he was previously used to. 

Lack of awareness of technical debt. Lack of awareness of technical debt causes the actions of people involved in software development to unconsciously create technical debt. It is assumed that having awareness of debt would cause a significant reduction in the creation of debt.  

Lack of knowledge about the risks associated with technical debt. Different types of technical debt are associated with different amounts of project risk.  Understanding the risks that a particular technical debt may cause is important to achieving the project objective. 

Consequences of technical debt 

Project completion time. Due to the growing technical debt, it is very difficult to estimate the time needed to complete the project. The debt causes that software development is prolonged and the gaps between product releases increase. In the IT area, the speed of releasing new versions of software upgraded with new functionalities shows the competitiveness of the product. Delaying the release of innovative products even by a few weeks may make us cease to be innovative and customers will choose the competitor’s product. 

As technical debt increases, the complexity of the code grows, which means that even the smallest changes require much more work. With more work, the cost of product development and repair goes up. In order to save money, implementations of additional functionality and bug fixes are suspended.  This situation makes the product unattractive, so it is not eager to buy, and thus the revenues from its sales decrease. Such a development often results in exceeding the project budget even before its completion, which may cause its discontinuation. Additionally, the production process and subsequent maintenance of the entire infrastructure (support, code maintenance) can prove to be more costly than the revenue incurred. 

The complexity of the code and its low predictability, caused by technical debt, make finding and then correcting bugs difficult and time-consuming. As a rule, in such situations, in the immediate period before the release of the  

As a rule, in such situations, in the immediate period before the release of the product, the correction is abandoned, not only because of lack of time and resources, but also for fear of introducing additional defects to the code. Such actions can lead to the released product becoming unpredictable and difficult or impossible to use. A large number of bugs indicates the quality of the product, and this again affects the number of licenses sold, and thus, profits. Technical debt, which is associated with the design layer or the technology layer, means that the product can operate well below optimum performance.  In markets where competition is very high, the aspect of product performance or even insignificant additional functionality  can be an indication of a product’s competitive advantage. – Subsequent product releases. Subsequent releases usually contain revised errors of older releases and new functionality.

All the above-mentioned problems, even if they are not in themselves the reason for the failure of an IT project, cause growing frustration. Dissatisfaction grows among both customers and employees responsible for product development. On the part of developers, designers or testers, dissatisfaction grows due to the monotony of work resulting from the constant struggle with obstacles. All activities are focused on correcting imperfections of the code, no progressive work is undertaken. Activity in this mode is not very developing, boring and tiring. It should be noted that in the IT sector, one of the main motivational factors is interesting work that allows for the improvement of skills. Employees participating in projects overburdened with technical debt very often run away from them, looking for new jobs. This causes additional problems related to the recruitment of new employees, their training and implementation, and above all the outflow of experienced workers. Also customers, dissatisfied with many imperfections, delays, low quality of software, lose their trust in the product. Sometimes the whole company is seen through this prism and loses its reliability. 

How to fight with technical debt? 

Now that you know what invisible technical debt is you can try to deal with it. Overcoming it in its entirety will be very difficult, but we can at least try to significantly minimize its effects.

It all starts at the IT system design stage. Usually at this stage we think about the application architecture, the API, the functionalities, etc. However, we often miss one thing. Already at this point it is worth thinking about how the application will be run. It is worth to optimize the way of launching to the requirements of a particular application. It is especially important in case of cloud computing, where many services are available. Choosing and configuring the right ones can be the key to success.

If we postpone these tasks, we will lack time for proper analysis. The choice is very wide, and if we choose wrongly we can contribute to failure. A significant part of the failure of information systems is related to the infrastructure. Therefore, at the same time when the application code is created we should develop the infrastructure and as soon as possible conduct tests on the environment similar to the production one. It is very hard to deal with problems resulting from improper or missing procedures and documentation. Usually we create these two things reluctantly, and on top of that they get outdated quickly.

The easiest thing to say would be that we should just do it and be done with it. However, there is something else that can also help when disaster strikes. The application should be equipped with the right solutions to monitor its performance. Metrics and dashboards created based on them can be the best source of information about the emergence of a problem, as well as where it occurs. Time spent on preparing tools to enable accurate monitoring of the application by the maintenance team can save us from many failures. Early noticing of an upcoming problem will allow to fix it before a serious failure occurs.

Monitoring is also a valuable source of knowledge about the behavior of the application when it is not working properly. Besides, how can we know if our system is alive if we don’t know its vital signs. It’s also hard to deal with people-related problems. We don’t have much influence on users, but we can influence people involved in creating and maintaining the application. The most important thing is partly on the side of the employee and partly on the side of the employer, and that is constant raising of competences. Internal training on the company’s products is the best opportunity to exchange knowledge necessary to operate the application.

In addition, constant raising of knowledge will help in choosing the right external components for a particular application. On the other hand, in case of failure, it will enable faster problem solving. There is one more thing that is worth doing, although it is not easy.

The creation of debt can be prevented already at the stage of software development by introducing the so-called code review. Team members should review each other’s code before it is put into the repository. As a rule, people evaluate the fruits of their work less critically than others. Such peer review improves code quality and helps maintain common standards.

Technology debt appears in every IT project and is visible at various stages of the project. We can incur this debt consciously, thereby gaining a competitive advantage early in the development and deployment of a new solution. Sometimes we take over a project with visible debt, and sometimes it grows with the progress of our team’s work. The IT world moves inexorably forward, forcing us to constantly evolve and sometimes look for shortcuts. The most important thing is to be aware of what stage the project is at and using your knowledge and experience, keep the debt in check.

At Concise Software we know how to counteract technology debt. We use practices that allow us to protect ourselves from its unforeseen consequences. Check out our experience and use it as an advantage for your business! 

You may like to read:
React Hooks – revolutionary changes in React
React Native vs Swift (native iOS) – clash of the titans
Swift vs Objective-C: Which language should you choose for your project?
Different software test types and everything you should know about them
GraphQL, Hyperledger Fabric & Go – what you need to know?
Code reusability vs. programming principles
Need data validation? Check out Joi – it will be useful!
Code cleaning – is it worth the time spent on it?
What is Kubernetes? Here’s what you need to know
Server-Sent Events: lightweight alternative for a few websockets use cases. SSE vs. WebSockets!