We don't need more. We need less.

Every week:
🧠 A new framework.
⚙️ A new "layer".
🤖 A new AI wrapper.
🔄 A new YAML format to abstract what used to be a shell script.

And then we wonder:
"Why is our software hard to debug?"
"Why do our builds break randomly?"
"Why is onboarding a 6-month journey through tribal folklore?"

I once said I write bug-free software that can be finished.
People laughed, especially product people.
Not because it's wrong.
But because they’ve forgotten it's possible.

We build complexity on top of confusion:
A + B becomes C.
C + D becomes E.
Now, E is broken, and we would create a new layer, but nobody knows how A or B worked in the first place. For example HTML/JavaScript, we leave it there and just add layers around it.

Take XML.
Everyone says it's ugly.
But you could validate it automatically, generate diagrams, enforce structure.
Now we're parsing YAML with 7 linters and still can't tell if a space is a bug.

Take Gradle.
You can define catalogues, versioning, and settings, but can't update a dependency without reading 3 blogs and sacrificing a goat.
This is called "developer experience" now?

Take Spring Boot.
I wouldn't trust a Spring Boot or any java Framework powered airplane.
Too many CVEs. Too much magic. Too little control.

We don't need "smarter" tools.
We need dumber, boring, reliable defaults.

Start boring.
Start small.
Then only change the 1% that needs to be fast, clever, or shiny.
You'll rarely even reach that point.
Like everyone says, "Y is more performant and faster than X", but no one reached the limit of X. Why should I care? Meanwhile, we use performant AI.

Real engineering is not chasing hype.
It's understanding the system so deeply that you no longer need most of it.

We've replaced curiosity with cargo cults.
We've replaced learning with LLM prompting.

And somehow, we're surprised when AI loses to a 1980s Atari in a chess game.
At least the Atari understood its own memory.

Simplicity = less maintenance = fewer bugs = happier teams.

We need less. Not more.
#devex #simplicity #softwareengineering #nocodependency#stopthehype #bugfree #springboot #gradle #xml #yamlhell #boringisgood #minimalism #AIhype #infrastructure #cleancode #pragmatism #java #NanoNative

@Xanatos
You should definitely give #nuke (https://nuke.build) a try!
I worked on a small nuget package based on that library which aims at solving the exact problem you're facing : being able to run the very same pipeline both locally and on your ci environment so that whenever you need to debug it... Well you can!
It's called Pipelines (https://github.com/candoumbe/pipelines) and the idea is to avoid the #yamlhell when working on a dotnet project.
Smart automation for DevOps teams and CI/CD pipelines | NUKE

Make yourself at home with build automation that is bootstrapped with simple .NET console applications and build steps that are defined as regular C# properties. Integrate your builds in CI/CD environments within seconds and without the usual YAML struggle.

Work these days seems to be figuring out a new templating thing for creating YAML every year or two. This year for me it’s helm charts. #devops #YAMLhell #k8s #kubernetes
Ugh, after template expansion this CI is 55000 lines of yaml. #yamlhell