This blog post is also available as a podcast

Technical debt can be a silent killer, and it could lead to severe consequences for eCommerce businesses. Budget loss and slow motion may be the signs of non-resolved tech problems. If these problems increase over time, there is a real risk of falling into technical debt. Introducing changes in the project’s initial phase is affordable and inexpensive, but the later a company realizes it has a problem, the greater the cost. Recognizing and addressing technical debt is crucial for the long-term success of an eCommerce business.

This article explains the definition of technical debt, how to avoid it (whether a business can avoid it at all), and why software support and future proofing can help create viable eCommerce companies.

What is technical debt?

The concept of software and technology debt appeared as early as the 1980s. However, Ward Cunningham – the man behind The Manifesto for Agile Software Development, introduced this concept in 1992 as a technology and software component. He has described the concept of technical debt as follows:

“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. Objects make the cost of this transaction tolerable. 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.”

When a software vendor needs to make a product delivery on time, they should make a compromise between its code quality and its functionality. Product development strategy demands continued effort because the “old” and “new” concepts may not be compatible.

  • Technical debt appears ALWAYS – it arises as part of the software development process
  • When the software becomes more complicated, it is often revealed that one change may affect the other
  • Technical debt is measured in time (and it is a time needed to correct mistakes)

Technical debt impact on productivity

Technical debt in IT systems can be compared to an old car. From time to time, something breaks down, and the only change you may introduce is spending money on the repair (so you can’t “update” your car [system]).  Sometimes it just feels best to move away from your old vehicle (system) in favor of a new, leased car. Ultimately, the cost needed to repair your old car may be the new car’s installment cost.

In the longer term, technical debt may lead to:

  • Too high costs of introducing changes to the code
  • A high number of errors in the software
  • Decrease in performance, reliability

What is technical debt in the context of eCommerce?

Complications that appear in outdated systems make implementing new solutions more expensive. If you try to “reanimate” old solutions, it may turn out that many bugs and bottlenecks appear. It will cause a situation that projects will exceed the budget and will not be delivered on time. Sometimes, it may be cheaper to choose another solution (e.g. eCommerce platform).

McKinsey conducted research among the directors of IT departments in companies providing financial and technological services. The annual revenue of those companies was greater than or equal to $ 1 billion.

The survey shows that 10-20% of the technology budget allocated to new products is used to solve technical debt problems. Even more worryingly, CIOs have estimated that technology debt is between 20-40% of the value of all their technology assets before depreciation. It translates into hundreds of millions of dollars in outstanding debt for larger organizations.

60% of those polled believe that their organization’s technical debt has increased significantly over the past three years.

Technical debt is a part of software development, but it can be at different levels – when it doesn’t interfere with work, it is assumed that it doesn’t exist.

Why is eCommerce vulnerable to technical debt?

eCommerce projects use many open-source and other packages (which may be in different standards and quality – e.g. different libraries and packages that are not updated). It is worth checking if each product/vendor is safe by using CVE vulnerability data.

Examples of implementations related to the technical debt:

  • Holiday promotion
    One eCommerce store was working on a holiday promotion, so software developers were asked to implement some new functionalities. As the system was having a lot of dependencies, it took some time, and as a result, they had to work under the pressure of time. What was the result? There were no tests; the code quality was poor. What was worse –  when the holidays came, suddenly the whole store stopped working.
  • Limitations in eCommerce B2B
    Organizations wanted to add prices depending on a specific group of clients. Their current platform did not support it, so they switched to another eCommerce system. Implementation time in their current system has been estimated at half a year of development, while in the second system, it might take 2-3 weeks. The second system had no tech debt, so the development process could go ahead without worrying about what might happen along the way.
  • eCommerce system migrations
    Every time businesses decide on migration, there’s a reason. It may be the moment when maintaining and developing the system ceases to be profitable. The business is able to make changes (and wants to change something) but is blocked by technology/system limitations. A company comes to a point when it asks itself the question -“Is it worth continuing to invest in a solution burdened with technical debt, or is it better to abandon it and build it from scratch?”. Referring to the example given above, maintaining and repairing an old car may be in line with the cost of leasing a new car, and the vehicle being repaired is not “earning”. The same situation appears with the eCommerce system.

For companies that do not have appropriate customer behavior analytics in place, it’s hard to tell how much money is actually being lost.

However, there are situations in which technical debt is not an obstacle to running a business. What’s more – a company doesn’t even have to reduce technical debt. For example, WooCommerce (which is burdened with technical debt from the very beginning) is an excellent solution for someone who does not need to rummage in sources and fix the world but only wants a ready-made solution that will just work and handle essential events.

Where does it come from?

There are many reasons for its formation; some of the most common are presented below:

  • Imprecise requirements for the eCommerce platform and its functionalities that appear during the implementation
  • Time pressure – adding features despite errors, which will be “patched later” that accumulate technical debt
  • Not flexible software architecture – which makes it impossible to adapt the platform to external integrations quickly
  • Lack of standards, manual testing, and good practices in the initial phases of platform implementation
  • Changes in requirements during implementation (e.g. to lower the total cost)
  • Failure to define the overall business strategy and identify the opportunities needed at the enterprise level
  • A poor match between IT solutions and business needs – mismatch in terms of funding, strategy, and resource allocation
  • Using outdated platforms and solutions
  • No updates of hosting environments, applications, databases, and others
  • Deciding on monolithic structures despite microservices
  • No scalability of the eCommerce system
  • Problem with access to specialists who can find solutions tailored to a given business strategy
  • Lack of appropriate knowledge and competences
  • Inappropriate team selection that can lead to communication deficiencies/errors

To examine, if you are struggling with technical debt in your system, you may want to think about those questions:

  • Is the development process slowed down?
  • Are there any downtimes?
  • Do the same bugs return or appear that were very hard to reproduce or fix?
  • Does the time of implementing new features increase while performance decreases?
  • Are your developers escaping from the company or don’t want to work on a specific project?
  • Did you push your development team to implement new features faster than they estimated?

Most of the affirmative answers to the above questions may signal change.

The consequences of having technical debt, in general, may lead to:

  • Higher costs of updates or even rewriting systems in the event of significant business growth
  • Higher costs of updates to improve system performance
  • Higher costs of security updates in the event of a threat
  • A decline in the company’s value (with leaky and inoperative systems)
  • Reduced customer satisfaction

Types of technical debt

Technical debt can happen for different reasons during software development, so it can have many faces. We have highlighted four possible types of technical debt below.

Planned technical debt

This type of technical debt is caused when a company is aware that it is generating technical debt and knows the full consequences (risks or expenses). Therefore, it is crucial to define how the organization intends to find a compromise between technical debt and business development.

Software entropy

Software entropy, also called bit-rot, occurs over time when the quality of the software progressively declines to result in unusability, errors, or required updates. It slowly degrades software performance over time or increases its response time, eventually leading to increased software bugs, unusability, and the need to update.

Entropy occurs when developers make incremental changes to a project that increases complexity, violates non-functional requirements (NFR) if necessary, or gradually breaks code structure.

Unavoidable technical debt

Unavoidable debts arise due to businesses changes and technological advancements that offer better solutions over the years. Usually, it occurs if unplanned modifications are requested during a planned project, resulting in a direct cost. Technical debt arises when a business’s requirements influence the obsolete code.

Unintentional technical debt

It arises from the consequences of interpersonal relationships, such as poor communications within an organization miscommunication between the developers/operational team/managers.

When should you pay more attention?

  • At the first moment, when you lose control of the system
  • When simple functionalities start taking too long to implement
  • When the introduction of one functionality breaks the other
  • When it becomes everyday/normal
  • When your business development is limited by technology
  • When you experience data leaks

When ‘good enough’ strives for perfection

Developers are always forced to balance their work ethic and the fact they need the highest quality code to produce a successful application. Clean code helps make the next iteration and improvement easier to implement. However, deadlines and limited resources often cause constraints in the development.

Development hours wasted on rework or fixing defects

How do we prevent and manage technical debt in the development process?

First, you need to be aware of such a problem from the very beginning. By properly managing technical debt, eCommerce businesses can ensure a more stable, scalable, and sustainable software ecosystem. Here are the best practices eCommerce merchants can employ to prevent technical debt in the development and maintenance of their eCommerce websites.

  • Take care of good-quality code and appropriate architecture and use proven solutions (not necessarily the fastest, but flexible that will allow you to scale the application in the future).
  • Companies that are looking for easier platform implementation management should look for solutions such as headless. It is a software platform structure that separates the front end from the back end. It gives freedom of integration, easy expansion of the eCommerce system with new functionalities, easy opening of new channels based on the API interface, and many more.
  • Test the product. It is worth testing the application and correcting emerging errors on an ongoing basis. Regular code reviews should be the basis of any software development.
  • Plan your project accordingly. Proper planning of software development should take into account both the time required to test the application and introduce current patches, as well as provide new functionalities. Focusing solely on the second aspect leads to the emergence of technical debt.

Choosing a solution “without technical debt”, gives no guarantee that it will not affect business. You have to take care that you can select the right people.

Want to know more about Sylius?

How to cope when you deal with technical debt?

In some cases, it is not necessary to rewrite the entire application from the very beginning. However, if you want such a solution, it is worth considering it carefully, considering the costs and time necessary for its implementation. However, it is best to analyze the problem at the initial stage and see where the most errors appear. At this point, the aforementioned code review can be beneficial, as it will allow for a comprehensive audit of the written code and identify the most problematic areas.

It might be a good idea to break your application down into logical smaller parts that will be refactored separately. After isolating them, it is worth analyzing the possibilities of improving the situation. Depending on the design, some parts of the application can be rewritten, and in others, the necessary corrections can be implemented step-by-step in strategic places.

Paying off the technical debt accumulated in MVP stages helps to restore good development pace

When is it worth trying to fight/How to fight

  • Raise the team’s qualifications (courses, training, qualifications)
  • Consider whether it is profitable to fight it or whether migration to the new system is better / cheaperMigration may take place step by step, e.g. first overvoltage the basket
  • Introduce standards; reverse engineering of what has been done so far
  • Writing tests, good programming practices – DDD, event sourcing
  • Looking at the situation from the side → is the team responsible for the technical debt able to cope with the new project
  • Bottega IT Minds → helps in getting out of technical debt
  • Observe the competition → who did it, how, what solutions / technologies / teams they used (we don’t get paid for mentioning them here, they are just that good)
  • Just because a business has a vision doesn’t mean it can be implemented. The best-of-breed approach → sometimes it is good to delegate some part of the logic to external solutions/vendors, such as marketing automation (SalesManago), invoicing

When is it not worth trying to fight

  • When you know that you can accept this debt – You will not develop this solution, and you only need it “for a while”
  • When rewriting the solution can take years
  • When there is a small (short) technical debt

Examples of technical debt based on popular open-source projects

To sum up, the appropriate work of the team and awareness of the consequences of technical debt allows you to fight this problem and minimize the resulting debt effectively. Of course, it usually takes time and requires the right plan, but the benefits of getting rid of your debt will be precious for your business.

If you need a consultation on the topic covered in this article and want to take your project straight, please get in touch with us – we will advise you on choosing the best solutions.