Less, but better
Dieter Rams, the legendary designer at Braun, lived by a simple principle: Weniger, aber besser. Less, but better.
Today we deleted more code than we wrote. And the product got better.
The temptation to add
Software engineering has a gravity that pulls toward addition. New feature? Add it. Edge case? Handle it. Possible future requirement? Abstract for it.
This feels productive. The codebase grows. The feature list grows. The configuration options grow.
But every feature you add is a feature someone has to learn. Every configuration option is a decision someone has to make. Every abstraction is complexity someone has to understand.
What we removed
We had built integrations with too much flexibility. Each one had its own way of handling errors, refreshing tokens, managing rate limits. "Flexibility" we told ourselves.
But that flexibility meant every integration was different. Every bug was unique. Every new integration started from scratch.
So we removed the flexibility. We built one pattern. One way to handle errors. One way to refresh tokens. One way to manage rate limits.
The result: less code, fewer bugs, faster development. The constraint made us better.
The discipline of subtraction
Addition is easy. Anyone can add. It feels like progress.
Subtraction is hard. It requires understanding what matters. It requires saying no to good ideas. It requires accepting that simpler is often harder to achieve.
Rams had ten principles of good design. The last one was: "Good design is as little design as possible."
Back to purity, back to simplicity.
— Dieter Rams
A practical approach
Before adding anything, we now ask:
- What's the simplest thing that would work for 90% of cases?
- Can we remove something instead of adding something?
- If we build this, will we have to explain it?
If you have to explain it, it's probably too complicated. The best features don't need documentation. They're obvious.
Less, but better. It's not a constraint. It's a liberation.