The Most Expensive Word in Software Engineering: "Simple"
"This should be simple."
Few phrases have caused more delays, stress, and unexpected complexity in software engineering.
It usually starts in a meeting.
A feature request appears on a slide. Someone asks how difficult it will be. A product manager, stakeholder, or sometimes even an engineer looks at it and says:
"It's simple. We just need to add a button."
Everyone nods.
A week later, nobody is smiling.
Because the button wasn't the problem.
The system behind the button was.
The Dangerous Part of "Simple"
In software, things often look simple from a distance.
A login page looks simple.
An email notification looks simple.
A search box looks simple.
Until you start asking questions.
What happens if the email service is down?
What if the user changes their password on another device?
What if the search needs to handle millions of records?
Suddenly, the "simple" feature starts collecting requirements, edge cases, dependencies, and technical constraints.
The visible part was simple.
The invisible part never was.
Software Is an Iceberg
Most people see software the same way they see an iceberg.
They only notice what's above the surface.
The button.
The page.
The dashboard.
Engineers spend most of their time dealing with everything underneath:
Databases
APIs
Authentication
Security
Monitoring
Error handling
Legacy code
A feature that takes two minutes to explain can take two weeks to implement.
Not because engineers are slow.
Because real systems are complicated.
The Legacy System Surprise
The word "simple" becomes even more dangerous when old systems are involved.
Every company has that application nobody wants to touch.
The one built years ago by people who no longer work there.
The one that somehow powers half the business.
Adding a "simple" feature often means navigating code that wasn't designed for today's requirements.
What looked like a quick change becomes a journey through forgotten assumptions and unexpected side effects.
That's when teams discover an uncomfortable truth:
The hardest part of software isn't building new things.
It's changing existing things without breaking everything else.
Why Estimates Go Wrong
Many failed estimates start with the word "simple."
Not because people are careless.
Because humans naturally focus on what they can see.
We imagine the feature.
Engineers have to imagine the consequences.
And consequences are harder to estimate than code.
A small change can trigger large effects.
A large feature can sometimes be surprisingly easy.
Complexity doesn't always match appearance.
The Better Question
Whenever someone says a feature is simple, I've learned to ask a different question:
"Simple for whom?"
Simple for the user?
Hopefully.
Simple to explain?
Maybe.
Simple to implement, test, deploy, monitor, maintain, and support for the next three years?
That's a very different conversation.
Final Thought
The best software often feels simple.
That's what makes great products great.
But simplicity for users usually requires enormous effort behind the scenes.
So the next time someone says, "It's just a simple change," be careful.
In software engineering, "simple" is often the first sign that nobody has looked closely enough yet.