What is technical debt?
Using a specific example, I’ll show you how technical debt looks over several years. This post is mainly directed towards those representing the business side.
What is technical debt?
Conflict between IT and Business departments
The problem with understanding technical debt
Ecommerce implementation and technical debt
What can be inferred from the example illustrating technical debt?
Summary
Let’s start with a straightforward answer. Technical debt is a natural phenomenon where the cost of adding identical functionality to a given IT project increases as the IT project develops.
Suppose you are interested in the effects of technical debt, where the greatest conflict between IT and the business department lies in the context of this phenomenon. In that case, I invite you to read the rest of the article.
There are two reasons why technical debt creates areas of misunderstanding between IT and the business department.
Firstly, IT often cannot simply explain what technical debt is. It is said that more investment in coding is needed to avoid generating technical debt. Or, it is said that a project has a high technical debt, and something called “refinement” should be carried out. The business department wonders what that means and does not get a clear answer from IT.
It also often happens that a business asks a secondary question (since it does not know what it is, at least it wants to know whether this technical debt is important because it costs a lot, or can simply be ignored) about the cost of technical debt. The problem is that the IT department is often unable to determine this cost. And this is a big issue.
Combining these two aspects – not knowing the cost and not understanding the concept – results in businesses simply overlooking technical debt. Every IT project, including implementing B2B ecommerce, is associated with technical debt.
The problem is that technical debt is very elusive. No one reports its value. To illustrate, imagine we have a shop on Magento in the basic version, with no modifications or additional third-party modules. Pure code “straight out of the box.”
Then we decide to add a module to help manage discounts. Assuming we have Magento in the basic version, adding this module takes 16 hours (as estimated by the agency we work with).
However, if we wanted to add the same module to a Magento project that has already implemented 20 modules and custom-modified code, adding the identical discount module could take 64 instead of 16 hours. The fact that developing a project with additional functionalities becomes increasingly expensive is what we call technical debt.
Technical debt is often not noticeable in the budget. This is because when you settle with an ecommerce agency, you usually determine a specific number of monthly hours that the agency will dedicate to working on your IT project. The business side doesn’t delve into how many of these hours are spent on fixing errors, actual development, software version upgrades, etc. It is usually the case that the business simply knows that collaboration with the agency takes up 80 hours per month x 70 EUR = 5.600 EUR and that’s it.
Let’s assume you pay for 80 hours, as in the example. For 5 years each month, you pay for the same 80 hours. The problem is the changing ratio of hours between maintenance and bug fixing versus development.
In the first year, it’s 20 hours of maintenance and bug fixing and 60 hours for development. By the fifth year, this ratio is 40 to 40.
Businesses don’t always see that the number of hours spent on maintenance and bug fixing is rising, meaning maintaining Magento costs more and more. They only see the consistent number of hours that are being spent.
Over time, the business begins to notice that less work is being done for the same 80 hours, more errors occurr, and the service develops more slowly. More resources are going into resolving conflicts and other bug fixing tasks, which IT reports as maintenance.
This observed phenomenon is the repayment of the incurred technical debt. In reality, you’re paying the software house the same 80 hours monthly, but a larger portion is devoted to maintenance and bug fixing.
Let’s immediately clarify that this does not necessarily mean that the ecommerce agency has worsened the quality of its work and has started hiring only inexperienced people. A significant impact on the amount of technical debt is which programming decisions were made at the system design stage.
There arises a question as to whether the way the initial online store or B2B ecommerce was coded and the choice of ecommerce agency influenced the division of hours between maintenance, bug fixing and development. Let’s analyze two situations.
In the first scenario, we have an online store that costs 115.000 EUR to implement. Maintenance and bug fixing over that time amounts to the number of hours multiplied by the hourly rate of 70 EUR, taking into account an annual inflation of 6%.
After calculating everything, maintenance and bug fixing come to 145.000 EUR over 5 years. In total, for implementation, maintenance, and bug fixing we pay 260.000 EUR. This example does not intentionally include the development budget, to show a certain phenomenon.
Now let’s assume we decide to reduce the costs of implementation. We turned to the ecommerce agency with a request to reduce the price but keep the same range of functionalities.
In such a case, the agency usually starts using more third-party modules already written and ready for implementation. In theory, they should work flawlessly, but unfortunately, this is not always the case.
By using more third-party modules, we can reduce the cost of implementation. Imagine that we managed to save 20.000 EUR on implementation. That’s a significant sum. Thanks to this, the cost of implementation is not 115.000 EUR, but 95.000 EUR. We achieved these savings by applying more third-party solutions that fulfilled the functional scope and made the service work.
Unfortunately, due to a large number of external modules, conflicts arise in these modules with every Magento upgrade, attempt to modify a module, or add new functionality to Magento. This forces us to eliminate bugs constantly.
In the first year, we no longer spend 20 hours on maintenance and 60 on development, but 40 hours on maintenance and 40 on development. With the project’s development, due to technical debt, we spend more and more on maintenance and bug fixing.
By the fifth year, we will spend 70 hours on maintenance and fixing errors, and only 10 hours per month on developing the service. Other variables, such as the hourly rate of 70 EUR and the average annual inflation of 6%, remain unchanged.
When we sum up the maintenance and problem-solving costs, it turns out that over 5 years they will amount to 255.000 EUR. That’s 110.000 EUR more than in the previous case.
So what have we done? In short, we saved 20.000 EUR on implementation. But the reality is that we didn’t save that money per se. We rather incur technical debt, an obligation that we will have to repay, paying interest on this obligation. We took a “loan” of 20.000 EUR and will repay the principal with interest amounting to 110.000 EUR over the next 5 years.
As a result, during this period, we will spend 90.000 EUR more, although the implementation phase cost us 20.000 EUR less.
This is a very realistic example of a situation where we save too much on implementation costs—of course, provided that these costs do not result from a lower hourly rate.
We save by using more Magento third-party modules and trying to combine them so that our service works. I have prepared a separate post on third-party modules, which you can read to find out why we usually advise against using a large number of third-party modules.
If you manage a company that owns a store on Magento, this may be the first time you see these costs. Perhaps no one from IT has provided you with this data before. If we decide to make such savings, being aware of the risk is a well-thought-out decision – we do not have funds now, but we will acquire them in the future and repay the debt – then it is acceptable.
However, it is unfavorable if you decide to lower the implementation costs without knowing what the financial consequences will be in the future. This example lets you know how it will affect your business.
Let’s move on to what we can learn from this simple example.
The first conclusion is that technical debt will always occur. This is because a project will always develop; we will always add additional functionalities and additional integrations. The way they are added and the coding practices influence the level of technical debt. It can be manageable, relatively light or very high.
The second conclusion concerns the costs of technical debt, which are incredibly high. It seems to me that this is one of the most frequently overlooked financial information when a business decides to implement a certain IT solution.
Some services use between 480 to even 1,000 hours monthly. If significant technical debt is generated at the beginning of the project, a large part of these 1,000 hours is spent on maintenance and bug fixing. This is a problem.
The third conclusion has to do with the types of sources of technical debt.
The first is natural, which results from project development. As additional functions, necessary for competitiveness in ecommerce, are added, the technical debt grows.
However, there is also an unnatural source of technical debt. This results from the excessive use of a large number of weak, third-party modules that are untested, incompatible with each other, and too complicated.
Unnatural technical debt is also generated when a Magento project does not have a properly designed system architecture or an architect controlling the process of altering it.
The system architecture is like a blueprint during house construction. If something was designed incorrectly at the beginning, like in a construction project, it is difficult to build a good building later. We will continually patch up and fix errors, a significant and costly problem.
If you decide on Magento and choose a software house, ensure the team has a certified architect (in the case of Magento, this is the Adobe Commerce Architect Master).
Another aspect that generates unnatural technical debt is coding that is not compliant with standards or unusual methods used by developers. This usually results from a lack of control in the project team or too little experience from the people working on the project.
The fourth conclusion concerns the question of how to compare offers from different ecommerce agencies and software houses to choose one that codes in a manner that does not generate a large amount of technical debt.
This task is not easy and it is impossible to discuss in this article. However, I promise that in one of the following posts, I will present this topic and describe exactly how to choose an ecommerce agency that will not generate unnecessary and large technical debt.
However, a good conclusion certainly would be that one of the criteria for choosing an ecommerce agency should be whether it has developed processes that ensure the maintenance of technical debt at a low level.
In this article, I described what technical debt is. In a nutshell, it is the phenomenon whereby the cost of adding identical functionality is higher as the IT project develops.
One of the critical conclusions regarding technical debt is that it can reach high values. Savings in the early stages of a project ultimately lead to the need to repay technical debt in the future. Technical debt has two types of sources: natural and unnatural ones that should be eliminated.
In my opinion, one of the business concepts that is most misunderstood is technical debt. I hope I have helped to some extent in facilitating the understanding between business and IT.
If you want to learn more about the topics that we believe are the source of much misunderstanding between IT and business departments, read our article about Total Cost of Ownership (TCO).
