From 65b31245fee98d2433b8fe8866cad09faac49764 Mon Sep 17 00:00:00 2001
From: Pierre-Olivier Mercier <nemunaire@nemunai.re>
Date: Fri, 13 Mar 2026 16:07:18 +0700
Subject: [PATCH] Add new article about complexity-is-the-lazy-solution

---
 .../complexity-is-the-lazy-solution/index.md  | 193 ++++++++++++++++++
 .../index.md                                  | 193 ++++++++++++++++++
 2 files changed, 386 insertions(+)
 create mode 100644 content/en/post/complexity-is-the-lazy-solution/index.md
 create mode 100644 content/fr/post/plaidoyer-simplicite-ingenierie-logicielle/index.md

diff --git a/content/en/post/complexity-is-the-lazy-solution/index.md b/content/en/post/complexity-is-the-lazy-solution/index.md
new file mode 100644
index 0000000..13ee532
--- /dev/null
+++ b/content/en/post/complexity-is-the-lazy-solution/index.md
@@ -0,0 +1,193 @@
+---
+title: Complexity Has Become the Lazy Solution
+date: !!timestamp '2026-03-13T15:08:00+07:00'
+translationKey: complexity-lazy-solution
+tags:
+- architecture
+- infrastructure
+- cloud
+---
+
+In software engineering, complexity is often seen as a sign of professionalism.
+
+A simple system looks suspicious.\
+A complex system looks serious.
+
+Yet my experience has repeatedly shown the opposite.
+
+<!-- more -->
+
+## A decade of success is not enough to convince
+
+In my final year of engineering school, I built a CTF platform.
+At the time, no tool like 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.
+
+The first year was a bit chaotic, as any first attempt tends to be.
+But iteration after iteration, the system stabilized.
+A few well-scoped micro-services came to structure the critical parts.
+And for ten years, it 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:
+
+- Why isn't there Kubernetes?
+- Why are you using the filesystem like that?
+- Why isn't there a REST API?
+
+I never managed to convince anyone.
+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.
+
+Since then, I keep asking myself the same 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.
+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.
+
+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.**
+
+Saying "it's slow" is not a diagnosis.
+It's an admission that you've lost control of your system.
+
+
+## A simple system is a mastered system
+
+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 a faster disk is necessary;
+- costs are genuinely understood, not just "10% less than last month."
+
+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.
+
+When the tools selling you performance are not themselves performant, that should be a signal.
+
+
+## The paradox of professionalism
+
+In many organizations, complexity has become a marker of seriousness.
+
+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.
+
+Yet to the executive team, if some "engineer's tinkering" works for 10 years, it must not 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.
+
+**A simple system looks amateur. A complex system looks professional.**
+
+This phenomenon has several roots.
+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.
+
+
+## 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.
+
+Sure, the core became a generic product, but everything around 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.
+You replace a system conceived as a whole with an accumulation of workaround layers.
+
+This is extremely 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).
+
+
+## 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.
+
+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?
+
+**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.
+
+
+## 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.
+
+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.
+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.
+An entire system can be generated in a matter of hours.
+This means **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.
+
+AI is a formidable tool for quickly pivoting toward alternative solutions, 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
+
+An engineer is not a code producer.
+Their role is to understand systems, master resources, 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.**
+
+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.
+
+
+## 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.
+
+And in a world where machines can generate increasingly complex systems, the engineer's responsibility is to keep those systems understandable.
+
+**Simplicity is not amateurism. It is what engineering produces when it matures.**
diff --git a/content/fr/post/plaidoyer-simplicite-ingenierie-logicielle/index.md b/content/fr/post/plaidoyer-simplicite-ingenierie-logicielle/index.md
new file mode 100644
index 0000000..04232a8
--- /dev/null
+++ b/content/fr/post/plaidoyer-simplicite-ingenierie-logicielle/index.md
@@ -0,0 +1,193 @@
+---
+title: La complexité est devenue la solution paresseuse
+date: !!timestamp '2026-03-13T15:08:00+07:00'
+translationKey: complexity-lazy-solution
+tags:
+- architecture
+- infrastructure
+- cloud
+---
+
+En informatique, la complexité est souvent perçue comme un signe de professionnalisme.
+
+Un système simple paraît suspect.\
+Un système complexe paraît sérieux.
+
+Pourtant, mon expérience m’a souvent montré l’inverse.
+
+<!-- more -->
+
+## Une décennie de réussites ne suffit pas à convaincre
+
+En dernière année d'école d'ingénieurs, j'ai construit une plateforme de CTF.
+À l'époque, il n'existait pas d'outil comme CTFd.
+Il fallait donc tout faire soi-même.
+
+J'ai fait des choix simples : servir des fichiers statiques pour réduire la surface d'attaque, générés lorsque nécessaire ; les services Unix classiques faisaient le lien entre les briques, les conteneurs bas niveau isolaient les services entre eux.
+
+La première année a été un peu chaotique, comme tout premier jet.
+Mais d'itération en itération, le système s'est stabilisé.
+Quelques "micro-services" bien découpés sont venus structurer les parties critiques.
+Et pendant dix ans, cela a tourné comme du papier à musique.
+Pas d'incident majeur.
+Pas de coupure à cause d'un service mal maîtrisé qui tombe.
+
+Pourtant, à chaque fois que je présentais l'architecture, je me heurtais aux mêmes questions :
+
+- Pourquoi il n'y a pas Kubernetes ?
+- Pourquoi utiliser le système de fichiers comme ça ?
+- Pourquoi il n'y a pas d'API REST ?
+
+Je n'ai jamais réussi à convaincre.
+Quand je suis parti, mon travail a été mis à la poubelle.
+
+La nouvelle solution repose sur CTFd : un produit générique qui nécessite beaucoup plus de puissance de calcul, offre moins de fonctionnalités et tourne bien sûr sur Kubernetes.
+
+Depuis, je me pose la même question : **pourquoi l'industrie informatique valorise-t-elle la complexité plutôt que la simplicité ?**
+
+
+## La complexité est devenue la réaction par défaut
+
+Aujourd'hui, face à un problème technique, la réaction instinctive est presque toujours la même : ajouter.
+Plus de machines, plus de couches logicielles, plus de cloud, plus d'abstractions.
+
+Le CPU est à 100 % ? On ajoute du CPU.\
+Le système est lent ? On migre vers le cloud.\
+L'architecture ne plaît pas ? On passe aux microservices.
+
+Mais ces décisions sont souvent prises avant même d'avoir compris le problème.
+**Quand un système devient lent, la réaction moderne est d'ajouter des serveurs. La réaction d'un ingénieur devrait être de se demander pourquoi.**
+
+Dire « c'est lent » n'est pas un diagnostic.
+C'est l'aveu que l'on a perdu la maîtrise de son système.
+
+
+## Un système simple est un système maîtrisé
+
+Je ne prône pas l'absence de technologie.
+Un système simple n'est pas un système rudimentaire.
+C'est un système où chaque élément a une raison d'exister.
+
+Un système maîtrisé, c'est un système où :
+
+- on sait pourquoi le CPU est saturé ;
+- on sait pourquoi on a besoin d'une carte réseau supplémentaire ;
+- on sait pourquoi un disque plus rapide est nécessaire ;
+- les coûts sont réellement compris, pas juste « 10 % de moins que le mois dernier ».
+
+C'est l'inverse de ce que je constate dans beaucoup d'entreprises.
+À commencer par les interfaces des fournisseurs de cloud : censées représenter l'état de l'art, elles sont elles-mêmes d'une lenteur frustrante.
+
+Quand les outils qui vous vendent de la performance ne sont pas performants, il devrait y avoir comme un signal.
+
+
+## Le paradoxe du professionnalisme
+
+Dans beaucoup d'organisations, la complexité est devenue un marqueur de sérieux.
+
+J'ai vécu ça de l'intérieur.
+Mon architecture Unix, mes fichiers statiques, mes micro-services légers : tout cela était perçu comme du bricolage.
+Pendant que les autres organisateurs dans l'événement se battaient avec leurs serveurs et CTFd, mon système tournait sans problème.
+
+Pourtant pour l'exécutif, si du "bricolage d'ingénieur" fonctionne pendant 10 ans, c'est que ce n’est pas si compliqué.
+
+À l'inverse, une stack avec Kubernetes, Kafka et un service mesh sera immédiatement perçue comme « une vraie architecture ».
+Même si personne dans l'équipe ne la comprend finement.
+
+**Un système simple paraît amateur. Un système complexe paraît professionnel.**
+
+Ce phénomène a plusieurs racines.
+Il y a le mimétisme : on copie les architectures de Netflix et Google sans considérer leurs contraintes.
+C'est l'équivalent de construire une cuisine de restaurant trois étoiles pour faire des pâtes.
+
+Il y a la peur du blâme : si le système casse et qu'on utilise « les standards de l'industrie », personne ne sera pointé du doigt.
+
+Et il y a l'effet CV : travailler avec Kubernetes et Kafka, ça valorise une carrière. Postgres et un monolithe, beaucoup moins.
+
+
+## Le *custom* ne disparaît pas, il se déplace
+
+Quand mon système a été remplacé par CTFd, au profit de la standardisation, le non-standard n'a pas disparu.
+Il a juste changé d'endroit.
+
+Certes le cœur est devenu un produit générique, mais tout ce qu'il y a autour : l'orchestration, les scripts, le scotch, les adaptations, sont devenus le nouveau *custom*.
+
+Et ce code-là est souvent pire : moins cohérent, plus dispersé, moins réfléchi globalement.
+On remplace un système pensé comme un tout par une accumulation de couches de contournement.
+
+C'est très courant avec les architectures modernes.
+On ne supprime pas la "complexité", on la déplace dans des endroits moins visibles et moins maîtrisés.
+Pire encore, il faut suivre les évolutions du standard constamment : adapter ses personnalisations, lutter contre les changements structurels, prier pour [les bonnes âmes](https://news.ycombinator.com/item?id=46136023).
+
+
+## Le cloud comme solution paresseuse
+
+Suite logique, le cloud est aujourd'hui la principale solution paresseuse.
+Non pas parce qu'il est inutile, il a des cas d'usage légitimes, mais parce qu'il permet de masquer les problèmes au lieu de les résoudre.
+
+Face à un problème technique, il y a deux chemins.
+Le premier : mesurer, comprendre, analyser.
+Le second : ajouter des ressources, empiler des abstractions, déplacer le problème.
+Pourquoi le second chemin est devenu la norme ?
+
+**Ajouter des machines est souvent plus facile que comprendre un programme.**
+
+Et c'est là que se situe la vraie paresse.
+Pas dans le choix d'un hébergement simple ou d'une architecture légère.
+Mais dans le refus de comprendre ce qui se passe réellement dans le système.
+
+
+## Le minimalisme n'est pas l'absence de complexité
+
+Certains systèmes sont extrêmement complexes et c'est normal.
+Le moteur de recherche de Google, les enchères publicitaires temps réel de Criteo, ... : ce sont des systèmes chirurgicaux où chaque brique est justifiée, parfois plusieurs fois.
+
+C'est exactement cela, le minimalisme en ingénierie : ne garder que la complexité indispensable.
+
+**La complexité n'est pas un problème. La complexité inutile en est un.**
+
+Une start-up avec quelques milliers d'utilisateurs et une équipe de cinq développeurs n'a pas les mêmes contraintes que Netflix.
+Pourtant, beaucoup déploient les mêmes architectures.
+
+
+## L'IA rend ce problème encore plus urgent
+
+Aujourd'hui, les outils d'IA savent produire du code et des architectures à une vitesse inédite.
+On peut générer un système entier en quelques heures.
+Cela veut dire que **la production de complexité n'a jamais été aussi facile**.
+
+Dans ce contexte, la compétence essentielle change.
+Elle n'est plus seulement de savoir coder.
+Elle est de savoir contenir la complexité produite.
+De rester en position de réflexion plutôt que de foncer tête baissée vers la première solution générée.
+
+L'IA est un outil formidable pour pivoter rapidement vers des solutions alternatives, pour explorer des approches différentes.
+Mais encore faut-il avoir le recul nécessaire pour choisir la bonne.
+
+**Les machines apprennent à produire de la complexité. Les ingénieurs doivent apprendre à la contenir.**
+
+
+## Le rôle réel de l'ingénieur
+
+Un ingénieur n'est pas un producteur de code.
+Son rôle est de comprendre les systèmes, de maîtriser les ressources et d'éliminer la complexité inutile.
+
+Un très bon ingénieur fait souvent *moins*.
+Un système bien conçu paraît presque trop simple.
+Et c'est précisément pour ça qu'il n'est pas reconnu : **le succès efface la perception de la difficulté.**
+
+Quand tout marche depuis dix ans, les gens finissent par penser que ça n'a pas dû être bien compliqué.
+
+Comme je l'entends parfois : aujourd'hui, la compétence la plus rare en informatique n'est pas d'écrire du code. C'est de savoir ne pas en écrire.
+
+
+## La simplicité est une discipline
+
+La simplicité n'est pas une absence de technologie.
+C'est le résultat d'un travail d'ingénierie exigeant.
+Ça demande de la mesure, de l'observation, de la réflexion.
+Ça demande parfois de résister à la pression sociale qui pousse vers la complexité.
+
+Et dans un monde où les machines savent générer des systèmes toujours plus complexes, la responsabilité de l'ingénieur est de garder ces systèmes compréhensibles.
+
+**La simplicité n'est pas de l'amateurisme. C'est ce que l'ingénierie produit quand elle devient mature.**