nemunaire/nemunai.re
1
0
Fork 0
Code Issues Pull requests 1 Releases Activity

Sync English article wording with French improvements

Browse source 
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
nemunaire 2026-03-22 13:12:29 +07:00
commit 654228073d
1 changed files with 86 additions and 73 deletions
Download patch file Download diff file Expand all files Collapse all files

159
content/en/post/complexity-is-the-lazy-solution/index.md
View file

@ -8,186 +8,199 @@ tags:
- cloud
---
In software engineering, complexity is often seen as a sign of professionalism.
In software engineering, complexity is often seen as a sign of competence.
A simple system looks suspicious.\
A complex system looks serious.
Yet my experience has repeatedly shown the opposite.
Indeed, a simple system looks suspicious, while a complex system looks serious.
<!-- more -->
## A decade of success is not enough to convince
## What is the value of a decade of success?
In my final year of engineering school, I built a CTF platform.
At the time, no tool like CTFd existed.
At the time, no software like [CTFd](https://github.com/CTFd/CTFd) existed.
Everything had to be built from scratch.
I made simple choices: serve static files to reduce the attack surface, generated on demand; classic Unix services glued the pieces together, low-level containers isolated services from one another.
It took me a lot of thinking to arrive at an architecture that looks simple in hindsight: serve static files, generated on demand, to reduce the attack surface.
Standard Unix services glued the components together.
Low-level containers isolated services from one another.
The first year was a bit chaotic, as any first attempt tends to be.
But iteration after iteration, the system stabilized.
Improvement after improvement, I managed to stabilize the system.
A few well-scoped micro-services came to structure the critical parts.
And for ten years, it ran like clockwork.
For ten years, the whole thing ran like clockwork.
No major incidents.
No outage caused by a poorly understood service going down.
Yet every time I presented the architecture, I ran into the same questions:
Yet every time I presented the architecture, I heard the same questions with a skeptical tone:
- Why isn't there Kubernetes?
- Why are you using the filesystem like that?
- Why isn't there a REST API?
- Why use the filesystem that way?
- Why not a simple REST API?
I never managed to convince anyone.
Here is the answer to the question about the value of a decade of success: I never managed to convince anyone.
A decade of success was not enough.
When I left, my work was thrown away.
The new solution is built on CTFd: a generic product that requires far more computing power, offers fewer features, and runs on Kubernetes, of course.
The new solution is built on CTFd.
In other words, a generic product that requires more computing power, offers fewer features, displays an austere interface, and runs on Kubernetes, of course.
Since then, I keep asking myself the same question: **why does the software industry value complexity over simplicity?**
Since then, I keep asking myself the question: **why does the software industry value complexity over simplicity?**
## Complexity has become the default reaction
Today, faced with a technical problem, the instinctive reaction is almost always the same: add more.
Today, faced with a technical difficulty, the reaction is almost always the same: add more.
More machines, more software layers, more cloud, more abstractions.
CPU at 100%? Add more CPU.\
The system is slow? Migrate to the cloud.\
The architecture doesn't look right? Switch to microservices.
The system is slow? Move everything to the cloud.\
The architecture doesn't suit anyone? Switch to microservices.
But these decisions are often made before anyone has understood the problem.
**When a system becomes slow, the modern reaction is to add servers. An engineer's reaction should be to ask why.**
According to my observations, these decisions are often made before anyone has understood the problem.
**When a system becomes slow, the instinctive reaction is to add servers and resources, whereas an engineer's reaction should be to ask "why?".**
Saying "it's slow" is not a diagnosis.
It's an admission that you've lost control of your system.
It's an admission of the loss of control over your system.
## A simple system is a mastered system
I'm not advocating for a lack of technology.
The most destructive phrase that now sets off alarm bells for me — one I encourage you to treat as a red flag whenever you hear it — is: "let's keep it simple!"
Why?
Because whoever says it often confuses "simple" with "simplistic."
In general, they're not from the field.
To be clear: I'm not advocating for a lack of technology.
A simple system is not a rudimentary system.
It's a system where every element has a reason to exist.
A mastered system is one where:
- you know why the CPU is saturated;
- you know why you need an additional network card;
- you know why the processor is saturated;
- you know why to add a network card;
- you know why a faster disk is necessary;
- costs are genuinely understood, not just "10% less than last month."
- you understand the details of costs, not just "10% less than last month" at random.
This is the opposite of what I see in many companies.
Starting with cloud provider dashboards: meant to represent the state of the art, they are themselves frustratingly slow.
Does that seem obvious? Yet I see the opposite in many companies.
Starting with cloud provider interfaces.
They're supposed to represent the state of the art, yet they are frustratingly slow.
When the tools selling you performance are not themselves performant, that should be a signal.
When the providers selling you performance are not themselves performant, that should trigger a signal in our minds.
## The paradox of professionalism
In many organizations, complexity has become a marker of seriousness.
In many organizations, complexity has become a marker of seriousness. Does that resonate?
I experienced this firsthand.
My Unix architecture, my static files, my lightweight micro-services: all of it was perceived as tinkering.
While other event organizers struggled with their servers and CTFd, my system ran without a hitch.
While other event organizers struggled with their servers and the CTFd software, my system ran like clockwork.
Yet to the executive team, if some "engineer's tinkering" works for 10 years, it must not have been that complicated.
Yet from the outside, "engineer's tinkering" that works for 10 years can't have been that complicated!
On the other hand, a stack with Kubernetes, Kafka, and a service mesh will immediately be seen as "a real architecture."
Even if no one on the team truly understands it.
On the other hand, something built on Kubernetes, Kafka, and a service mesh will immediately be seen as "a real architecture."
Even if those who truly understand it are rare.
**A simple system looks amateur. A complex system looks professional.**
This phenomenon has several roots.
In my opinion, this phenomenon has several roots. I've identified several, and there may be more.
There is mimicry: copying Netflix and Google architectures without considering their constraints.
It's the equivalent of building a three-Michelin-star restaurant kitchen to cook pasta.
There is fear of blame: if the system breaks and you're using "industry standards," no one will be pointed at.
And there is the résumé effect: working with Kubernetes and Kafka boosts a career. Postgres and a monolith, much less so.
There is the résumé effect: working with Kubernetes and Kafka boosts a career. Postgres and a monolith, much less so.
There is finally the abundance of cheap resources.
Why save on storage when disk prices keep falling?
Why save on RAM when adding more costs just a few dozen euros?
Why save on computing power when it's available on demand?
Yes, keeping things simple requires time from skilled people — who are rare and expensive resources.
## The *custom* doesn't disappear — it just moves
When my system was replaced by CTFd, in the name of standardization, the non-standard didn't disappear.
It just changed location.
When my successors replaced my system with the CTFd software in the name of standardization, the non-standard didn't disappear.
It changed location.
Sure, the core became a generic product, but everything around it — the orchestration, the scripts, the duct tape, the adaptations — became the new *custom*.
Sure, the core of the system became generic software.
But everything that completes it — the orchestration, the scripts, the duct tape, the adaptations — became the new *custom*.
And that code is often worse: less coherent, more scattered, less thoughtfully designed as a whole.
Guess what? That code is often worse: less coherent, more scattered, less thoughtfully designed as a whole.
You replace a system conceived as a whole with an accumulation of workaround layers.
This is extremely common with modern architectures.
This example is common with modern architectures.
You don't eliminate "complexity" — you move it to less visible, less controlled places.
Worse still, you have to keep up with the standard's evolution constantly: adapting your customizations, fighting structural changes, praying for [the goodwill of others](https://news.ycombinator.com/item?id=46136023).
Worse, you have to constantly keep up with the "standard" software's evolution: adapting your customizations, fighting structural changes, praying for [the goodwill of others](https://news.ycombinator.com/item?id=46136023).
## The cloud as a lazy solution
As a logical consequence, the cloud is today the primary lazy solution.
Not because it's useless — it has legitimate use cases — but because it allows you to mask problems instead of solving them.
As a logical consequence of this trend, the cloud is today the primary lazy solution.
Not because it's useless — it's legitimate for certain use cases — but because it allows you to mask problems instead of solving them.
Faced with a technical problem, I see two paths.
Faced with a technical problem, there are two paths.
The first: measure, understand, analyze.
The second: add resources, pile on abstractions, move the problem elsewhere.
Why has the second path become the norm?
Why has this second path become the norm?
**Adding machines is often easier than understanding a program.**
And that is where the real laziness lies.
Not in choosing simple hosting or a lightweight architecture.
But in refusing to understand what is actually happening inside the system.
It seems to me that the laziness lies here.
Not in choosing simple hosting or a lightweight architecture, but in the unwillingness to understand how the whole thing works and what is happening inside the system.
## Minimalism is not the absence of complexity
Some systems are extremely complex, and that's perfectly fine.
Google's search engine, Criteo's real-time ad auctions, ...: these are surgical systems where every component is justified, sometimes multiple times over.
Some systems are complex, and that's perfectly fine.
Google's search engine, Criteo's real-time ad auctions: these are surgical systems where every component is justified, sometimes multiple times over.
That is exactly what minimalism in engineering means: keeping only the complexity that is indispensable.
**Complexity is not a problem. Unnecessary complexity is.**
A startup with a few thousand users and a team of five developers does not face the same constraints as Netflix.
A company just starting out, with a few thousand users and a team of five developers, does not face the same constraints as Netflix.
Yet many deploy the same architectures.
## AI makes this problem even more urgent
Today, AI tools can produce code and architectures at an unprecedented pace.
Today, artificial intelligence tools can produce code and architectures at an unprecedented pace.
An entire system can be generated in a matter of hours.
This means **producing complexity has never been easier**.
As a result, **producing complexity has never been easier**.
In this context, the essential skill is shifting.
It is no longer just knowing how to code.
It is knowing how to contain the complexity that gets produced.
To remain in a reflective position rather than rushing headlong toward the first generated solution.
In this context, the skill is shifting.
It is no longer knowing how to code — it becomes knowing how to contain the complexity that gets produced.
It is about forcing yourself to think, rather than rushing headlong toward the first proposed solution.
AI is a formidable tool for quickly pivoting toward alternative solutions, for exploring different approaches.
Artificial intelligence is a formidable tool for quickly pivoting toward alternative solutions or for exploring different approaches.
But you still need the perspective required to choose the right one.
**Machines are learning to produce complexity. Engineers must learn to contain it.**
## The real role of the engineer
## The role of the engineer
An engineer is not a code producer.
Their role is to understand systems, master resources, and eliminate unnecessary complexity.
An engineer is not just a code producer.
Their role is to understand systems, master resources and costs, and eliminate unnecessary complexity.
A very good engineer often does *less*.
A well-designed system looks almost too simple.
And that is precisely why it goes unrecognized: **success erases the perception of difficulty.**
A good engineer often does *less*.
A well-designed system looks almost too simple, and that is often why it goes unrecognized: **success erases the perception of difficulty.**
When everything has been working for ten years, people end up thinking it couldn't have been that hard.
As I sometimes hear: today, the rarest skill in software is not writing code. It's knowing when not to.
Today, the rarest skill in software is not writing code — it's knowing how to avoid writing it.
## Simplicity is a discipline
Simplicity is not an absence of technology.
It is the result of demanding engineering work.
It requires measurement, observation, and reflection.
It sometimes requires resisting the social pressure that pushes toward complexity.
I don't confuse simplicity with an absence of technology.
Let's say it is the result of demanding engineering work.
This demanding work requires measurement, observation, reflection, and sometimes resisting the social pressure that pushes toward complexity.
And in a world where machines can generate increasingly complex systems, the engineer's responsibility is to keep those systems understandable.
In a world where people and machines alike can generate complex systems, the engineer's responsibility is to keep those systems understandable.
**Simplicity is not amateurism. It is what engineering produces when it matures.**