In our job, technical debt is probably the most frustrating, draining and tenacious thing we have to fight against. Of course, there are best practices: refactor, aim for simplicity with KISS, avoid over-engineering with YAGNI in order to keep this debt as low as possible. And yet, we never really manage to get rid of it. Worse, it keeps piling up even when we apply those principles, as if it were inevitable.

But what if those very best practices sometimes made the problem worse instead of solving it? Technical debt may be only the visible part of something deeper: accidental design debt. A far more complex problem that leads to spaghetti software and microservices that are really just a distributed monolith, and that we often create ourselves without even realizing it.

In this talk, we will explore the mechanisms of design debt and its impact on our architecture, our processes, our organization, and even our business. Through concrete examples, we will see how to detect it, assess how deep it goes, and act before it becomes entrenched for good.

We want to address the notion of design debt because it is still little known and understood in our industry. Many people are currently bogged down in the fight against technical debt because they are not tackling the real problem, lacking a mental model to reason about design debt (model tensions).

For Devoxx UK, we are proposing a popularized version of our latest talk, “Model Tensions Heuristics: preventing accidental design debt”, presented at NewCrafts 2025 and DDD Europe 2025. The slides and the recording of the original version have been provided.

1. Accidental design debt
Accidental design debt arises from the accumulation of seemingly minor choices that, over time, introduce coupling, reduce cohesion, limit flexibility, and erode the accuracy of business models.
We will highlight the link between this debt and the way we construct our domain models, and show how some best practices (DRY, KISS, YAGNI) can actually make the problem worse, because they are not addressing the right underlying issue.
We will explain how this debt leads to genuine spaghetti monoliths, through design entropy, that is, the tendency of a design to become disorganized and to dissipate ever more of our energy whenever we make changes.
We will introduce the so-called “Spork” model, which consists in trying to solve several distinct problems with one single solution.
2. Model tensions, the origin of design debt
We will introduce the notion of model tension: a “smell” indicating that we are forcing a change into a design that does not really fit it.
We will analyze why these tensions appear and how, as they crystallize over time, they become structural constraints that reinforce design entropy.
We will then put these tensions into perspective not only as a problem, but also as a valuable signal that allows us to anticipate and prevent the emergence of accidental design debt.
3. Practical illustration of these tensions
We will demonstrate these phenomena through several concrete examples:
In the construction of a domain model, in particular via an EventStorming workshop
In the design and structure of a REST API
In Java domain code
For each case, we will present possible remediation paths to identify, correct, or avoid these tensions.
4. The harmful and unsuspected effects of services heavily affected by design debt
We will illustrate the following mechanism: a rigid and complex service leads to the creation of a new microservice to bypass the inertia of an existing service, but functional coupling quickly appears, forcing both services to be deployed together.
We will show how these services eventually form a distributed monolith, because the root problem was never resolved.
We will highlight compensatory responses adopted at the process and organizational levels, such as the use of feature toggles or the emergence of “patch” roles whose purpose is to (over-)synchronize the work of teams in order to avoid making the information system too fragile.
We will analyze the organizational drifts caused by services that are heavily impacted by accidental design debt.
Finally, we will show that these organizational tensions are just another expression of the initial tensions present in the model, including the impact of Conway’s law.
5. Retrospective and ways out
We will show how we built a body of evidence by observing all parts of the company in order to identify and assess the depth of design debt.
We will conclude by opening up concrete levers for action to halt this dynamic and prevent the emergence of new design debt.

Slides Link
https://slides.com/julientopcu/you-thought-technical-debt-was-bad-meet-design-debt

Video URL
https://www.youtube.com/watch?v=EZTl9FH5AFQ