Sometimes there comes a date which must be circled on the calendar. It looks different for different people: for a programmer it can be a “spaghetti code” where it is necessary to add a new feature, and for an IT Director it will be the need to implement a new tool and integrate it with a complex ecosystem of years of patchwork IT infrastructure. Something that connects these situations, a specific phenomenon which often occurs at the last minute, may be something we are not yet aware of – the phenomenon of Technological debt.
This debt, even subconsciously, gives us a sense of comfort, as it allows us to indefinitely postpone hard decisions, effort, or even admitting a mistake. And this is life on credit, which Billy Gibbons warned of when he sang: “It’s too easy, it’s too easy to feel good,” lyrics which in this case are found in a bitter song about the consequences of postponing things until a later date.
Technological debt means additional work that must be done in order to accomplish a task, due to past neglect within the project. This phenomenon often occurs in IT projects when negligence in terms of the work done means that there is a time-based debt which should be devoted to getting the project up to the expected state. In the earlier example of the IT Director, facing the challenge of implementation of new tools, paying off the debt will be based on the fact that integration with obsolete and poorly-documented infrastructure, which may have been used for years, is likely to be a long and painful process. In addition to the implementation process, a lot of work will have to be undertaken to adapt the entire system and repair unsolved problems which have built up over the years.
Debt is also used to refer to problems that arise in sloppily written code. Personally, I am inclined to say that the problems themselves are not Technological debt, but more interest on the debt incurred. We incur debt while doing any activity that contributes to the delivery of any code which is not quite up to expectations, not only in terms of the tasks to be undertaken, but also performance, readability, maintainability, and how it can be developed in the future. There may be many reasons for this state of affairs.
To face up to a challenge which puts us in Technological debt, we must take a look at the causes, among which the following phenomena can most often be found:
This list is not complete, of course, and some aspects may be closely linked to each other. Programmers can write low quality code for many reasons: because of a lack of motivation, knowledge or experience, or because of time pressure or lack of proper tools. The programmer is often only an indirect cause of the debt, as management is the responsibility of the project manager who makes decisions regarding time, tools, technology, and how they are allocated – without outside input. Sometimes it is difficult to identify the causes of the debt. Small errors in a project or strategic decisions – such as the need to provide a solution in a very short time – can lead to the creation of such debt. The origins of the phenomenon in each project can vary and are very complicated, but it does not change the fact that, regardless of its origin, Technological debt must be managed effectively.
It would be a mistake to unambiguously define Technological debt as something that should always be avoided at all costs. Just as a loan may allow the company to spread its wings, Technological debt incurred reasonably can be helpful in many cases.
Technological debt may be divided into three types, which clearly show that not all debts are created equal:
It may turn out that the incurrence of debt brings with it very tangible benefits, especially in such situations as when the project hangs in the balance, and providing a sufficient batch of a program becomes “to be or not to be” for the project. The decision to incur such debt could even save the whole project (and sometimes the entire company). One should, however, take extreme care when making this type of decision, because poor management of the resulting debt can lead to disaster.
If we are aware of our debts, we are able to pay them off regularly – the debt itself is not a problem if it doesn’t harm ongoing operations. Ignorance in this case is absolutely not bliss, because we do not expect the impact, nor do we know when it will occur. Fortunately, in IT projects, symptoms that indicate the existence of the Technological debt appear quite quickly and are visible to the naked eye.
Here are a few diagnostic questions:
Even if the answer to all questions is no, you should not feel overly safe. Some experts are of the opinion that Technological debt is a permanent element of the possession or development of software and IT infrastructure.
So let’s assume that Technological debt occurs in every IT project in some form. This means that the effective management of the debt is very important. In other words, it is not enough to merely control and neutralize the effects – much more important is a methodical approach to the quality of the application, and preventing the occurrence of debt where we don’t want to incur it.
You need to manage debt and fight it on all fronts. The following are of crucial importance:
1. Building awareness of the importance of quality within the company. Quality itself must be seen as a value which we should care about. Without this, it’s difficult to manage debt, because we can’t do much without the proper approach from employees. Their involvement is key.
2. Controlling processes. Constant feedback about what’s going on in the project helps us to react quickly when issues arise.
3. Quality assurance. Caring about the quality of software, getting it checked by specialists, not just in terms of testing, but including all aspects of quality.
4. Tests. The quicker testing begins, the sooner problems can be found. Tests at the level of documentation and unit testing eliminate debt very quickly.
5. The application of best practices, such as:
6. Training employees.
7. Promotion of unit testing. As a basic tool, including TDD as a standard tool of creating software for programmers.
Just as before, unfortunately, this list is incomplete, as debt can have very different sources, often specific to a particular company, or even a project. A company should therefore develop its own technique of debt management – most importantly, it should not ignore debt until it’s too late – until disaster strikes and the bailiffs knock on the door.
Would you like to learn more about the possibilities of cooperation? Do you have a question? Write to us!
Comment