Whether for developers or corporate management, technical debt is a key issue. An obsolete code or a poorly consolidated implementation can lead to a lot of complexity, high costs and problems that need to be overcome through additional efforts. As a cloud service provider recognised throughout Europe, we obviously face this constant challenge. In this article, we share our experience of this issue through one of the flagship products of our suite of online productivity tools, the web interface that allows you to manage your online messaging.

Technical debt is often put to one side because it does not generate immediate value for the company, but it can quickly become a deadweight that hinders future progress. Julien Arnoux, VP of Engineering

The technical debt: a time bomb that can have a critical impact on business 

Delivering features appeals to the market. So often we speed up, even if this means ignoring the old parts of the code that “we’ll deal with later”. But when business objectives sweep the quality of the code under the carpet, this is what happens:

For developers: it’s frustration

Each iteration increases the debt. Despite this, we continue to evolve on the basis of software created X years ago and which no longer necessarily correspond to the needs of today. We can’t use the latest languages, pre-prod machines are not identical to production machines… We inflict obsolete practices on ourselves with increasing blockages and the risk of mistakes as well. As a result, we leave everything as it is for fear of breaking it. The mountain of engineering tasks is growing, stress is spreading to the teams who lose engineers because of the arduous work.  

From the manager’s side: it’s a lack of understanding

Usually we fix problems with quick fixes, but it now takes two weeks just to change the buttons of the interface. To try to meet unrealistic deadlines, we put pressure on developers who “lack rigour” while constantly struggling with technical problems and bugs. Productivity drops and it’s difficult to stay motivated.

For the management: nothing moves fast enough

Money and sustainability are at stake. Why does it take so long to deliver value? Why is the website slow? Why modernise the code when it doesn’t solve any of the problems expressed by customers? Decision-makers may, for example, be tempted to offset slowdowns with an immediate solution such as adding server power, despite the fact that this does not solve the underlying technical debt that will continue to impact code quality more and more in the long term.

The figures speak for themselves: in companies, technical debt is estimated to be responsible for +10% to 20% of costs on each project, for up to 13.5 hours of problem-solving per week per employee and about 30% of the annual IT budget.

If we can’t find the balance, we’re heading straight for a crash. The risks are clear:

  • Loss of speed
  • Security issues
  • Teams becoming demotivated (technical and product)
  • Poor quality software

But what exactly do we mean by technical debt?

Technical debt is the difference between the current code and what it should ideally be. So, the lower the quality of the software, the higher the debt.

It’s inevitable, regardless of whether it is intentional or not. 

You can sacrifice the quality of the code to turn a profit if you have a very short time to market or if a delay in the release of a new version is financially untenable, for example. In this case, the debt is intentional, but most often it is not because technical debt is inherent to our business.

It increases with each line of code 

The more we go through the iterations, the more we increase software complexity and disorder.

The first problem is the essential complexity of our business. For the Email Service, this means being able to interact with an email server quickly and efficiently and providing an API that can be consumed via a web app and mobile apps.

Then accidental complexity comes along, with problems resulting from poor code quality. It also depends on the technical choices made, for example:  during the redesign of the previous version of the Email Service, part of the codebase was recovered from the very first version written more than 15 years ago. This used a different storage system for emails. So we’ve inherited a lot of unnecessary complexity despite not using this system for a long time.

And finally, there is natural disorder (software entropy). We start with a simple software base to which we add modules throughout the service life of an app. The logic gets tangled up and becomes difficult to understand, especially if a developer leaves the team. We end up with pieces of code that no longer serve any purpose, but that increase complexity :

Which is what happens when technical debt builds up

We end up spending more time compensating for difficulties rather than creating features and really adding value to the software:

So, how do we deal with technical debt?

It is a question of balance, the trade-off between quality and cost, is almost the key question in software development.

Start by making it visible

It is important to convince everyone: your colleagues, your manager, your management. Not that easy? It is essential to translate technical debt for managers and CEOs by explaining the following points:

  • show them that short-term gains jeopardise long-term competitiveness;
  • explain that technical problems will turn into the loss of customers;
  • raise awareness that obsolete code reduces predictability and makes the project opaque.

“Modernising your code is not developer snobbery.” It’s a necessity for business:

Teams that reduce their technical debt free up to 50% more time to create value.

Stop the bleeding to prevent ongoing accumulation

You won’t change the culture of a team overnight, but you must be aware of the aggravating factors in order to minimise them:

  • unsustainable delays
  • needs not well defined
  • poor organisation of the company (siloing of teams)
  • lack of business knowledge
  • Technically speaking: bad practices, no docs, over-engineering, no testing, etc. 

3 principles that can also aggravate debt:

  • No quick fix. Frameworks that promise to solve all problems do not exist.
  • Avoid mimicry: “Netflix makes microservices”, “Google is monorepo”. Doing the same thing as others “because they do it” will not produce the expected results in a different context (see Cargo Cult). 
  • Broken window syndrome: this is the idea that if you leave a broken window in a building without repairing it, it will incite people to damage other windows in the building, then the walls, then the neighbourhood, etc. This is very common in software: we are less hesitant to push a piece of bad code if the general state of the code is already bad, and we end up with a mountain of spaghetti code to maintain.

Some principles that can be applied to avoid this:

  • The Boy Scout’s rule: try to leave the land (code) as clean as possible after visiting it as we found it when we arrived. Thanks for those who follow 😉 
  • K.I.S.S. : Keep it simple stupid (keeping it simple is complicated, but do it all the same).
  • Y.A.G.N.I. : You ain’t gonna need it (we developers are very good at adding things “in case” we need them…) 
  • D.R.Y. : Don’t repeat yourself (instead of duplicating your code, try as far as possible to factor it in another way).

Generally speaking, crafting techniques are a good resource.

How to repay the existing technical debt?

Now let’s get down to the nitty gritty. If we want to have the biggest impact: 

  1. Identify areas at risk for technical debt.
  2. Illustrate the benefits of treating them
  3. Categorise: security, maintainability, automation, quality assurance, continuous integration…
  4. Prioritise technical debts to be repaid according to their impact
  5. Process

For example:

  • “I have a dependence that’s been outdated for six months. It is no longer maintained and there are potentially security vulnerabilities.”
  • The benefit: “potentially avoid security breaches.”
  • This is then dealt with in relation to the other debts identified according to the priorities and the desired impact. 

Invest regularly to reduce existing debt 

Thanks to the identification work, it is possible to plan the repayment of the technical debt and incorporate it into the roadmap of the product/service. This procedure is therefore carried out with the product owner or the product manager.

Pay it all back? It’s all about a measured approach.

Technical debt is a long-distance race. It serves no purpose to seek code purity at all costs, but prioritising quality greatly contributes to the development potential. Not having software that is in debt attracts developers rather than scaring them away. The best thing to do is to re-evaluate the debt on a regular basis in order to recalibrate and always stay on the right track.

Find out more

The full technical debt webinar:

this conference presents what technical debt is, its origins, the risks involved and how to prevent and repay it. Julien Arnoux is VP of Engineering at Infomaniak. He has been in tech for over 15 years; first as a developer, then as a lead dev and finally as a VP. He has seen all the different aspects of web product development, from technical to organisational issues.