DEV Community: Eric Ndouakulu Kiaku Mbuta

Stop Calling It Technical Debt !

Eric Ndouakulu Kiaku Mbuta — Sun, 06 Sep 2026 18:43:07 +0000

In every project, someone says it sooner or later: "we have too much technical debt." Everyone agrees. Nobody asks how much.

One day I tried to do the math for real. I learned very little about my code, and a lot about the metaphor.

The bank statement

If my technical debt were a loan, it would have the same structure:

At the bank	In the code
The principal	The shortcut taken to ship on time
The interest	The extra cost of every new feature
Repayment	Refactoring
Bankruptcy	A full rewrite

So I listed my lines: a 3,000-line service with no tests, a framework three major versions behind, billing logic copied in four places, and one module everyone avoids.

Every feature costs me about 30% more time. And the principal, the amount I would need to pay to reach zero, is measured in months of work that nobody will ever give me.

The verdict: I am insolvent. And yet I ship every week, and I have been shipping for years. This is where the analogy breaks.

Four reasons why it is not a debt

I don't know the amount. A bank debt is a number written in a contract. Technical debt has no number, it has opinions. Ask three developers to rate the same module and you get three answers.

I never signed anything. You choose to take a loan. Most of my technical debt arrived on its own: a library abandoned by its author, a business rule that changed, a project I inherited. Ward Cunningham, who created the term in 1992, was talking about a loan you take on purpose, to learn faster. He then spent twenty years repeating that he never meant "badly written code."

The interest does not arrive every month. You only pay for the code you touch. I have terrible files that have not cost me a single minute in three years, because nobody goes there. And I have an 80-line file, changed twice a week, that is ruining me.

There is no zero balance. The refactoring I do today will be out of date in two years. I never repay anything. I just trade one debt for another one with a better rate.

The word itself is a problem

"Debt" suggests a mistake: someone spent badly. It makes teams feel guilty about decisions taken under pressure, and often taken by other people.

And a debt can be delayed. That is exactly what managers hear. The code, however, does not renegotiate anything.

What I say instead

Talk about friction, not a balance. Not "this module is technical debt," but "any change to billing takes three weeks instead of three days."
Talk about risk, not interest. An unpatched dependency costs nothing until the day it costs everything.
Talk about what we can no longer do. The argument that works is not "we need to refactor." It is "the feature you want in Q3 is not possible with the current architecture."

In practice, I compare how often files change with how complex they are. What moves often and hurts, I fix. What sleeps, I let it sleep, even if it is ugly.

Conclusion

I will never repay my technical debt, because it is not a debt. It is the gap between a system written yesterday and a world that kept moving.

Let's keep the word for what it first meant: a shortcut taken on purpose, with open eyes. For everything else, let's stop doing imaginary accounting and simply look at where it hurts and what it stops us from building.

This is not bankruptcy. It is maintenance. And maintenance has no final payment.

The "Service hell" and how you can avoid it

Eric Ndouakulu Kiaku Mbuta — Sat, 10 Feb 2024 08:05:57 +0000

In this post, I aim to shed light on the concept of "service hell" and offer strategies for circumventing such predicaments, emphasizing the critical role of service categorization for enhanced code hygiene.

What is "Service Hell"?

"Service Hell" describes a scenario in which an application is burdened by an overabundance of services, often characterized by vague responsibilities. This clutter leads to code that is challenging to comprehend, maintain, and expand. A lack of structured organization can result in repeated logic across services, undermining the principle of reusability.

Solutions to Navigate Away from "Service Hell"

1. Refine the Definition of "Service"

In contemporary development practices, any component that isn't an entity, repository, or a point of exposure (such as REST Controllers, GraphQL entry points, Kafka consumers, etc.) is often labeled as a service. However, this broad definition of service can be more usefully segmented into distinct categories:

Application Service: Acts as the functional gateway of our application, orchestrating and coordinating all internal components to fulfill the requested action.
Infrastructure Service: Expands our system's capabilities by interfacing with external components (e.g., HTTP clients to other microservices, email dispatching, etc.).
Domain Service: Augments our business model with additional functionalities that necessitate computations beyond the capabilities of the business object itself (e.g., calculating an exchange rate for an order).

Over time, the essence of what constitutes a Service, as discussed by Martin Fowler, seems to have been diluted.

2. Enhance Service Cohesion

It's crucial to ensure that each service class is assigned a clear and consistent responsibility. Adhering to the Single Responsibility Principle is advisable here.

3. Assess Service Granularity

The granularity of your services warrants careful consideration. Services that are either too granular or too bulky can pose issues. Striking a balance that aligns with your application's size and complexity is key.

4. Improve Organizational Structure for Clarity

Services should be organized in a manner that mirrors the business domain of your application. This organization might involve categorizing services by functionality, domain, or other logical divisions, facilitating a more intuitive understanding.

Your Thoughts?

This introduction serves as a starting point for further discussion on this topic. I welcome your insights and questions in the comments below.

My introduction

Eric Ndouakulu Kiaku Mbuta — Sun, 17 Dec 2017 21:26:37 +0000

I started coding when I was 18 years old

I live near Paris.

I work for Mirakl in France.

I mostly program in these languages: Java, JavaScript, Kotlin, Go

Sharing is my philosophy

I am currently learning more about Reactive System, Rx, functionnal programming, concurrency over parallelism, Vert.X

You can find me on GitHub as endouakulu

Nice to meet you.