On building simple systems
Why the best software is often the software that does less. Thoughts on restraint in system design.
There’s a recurring pattern in software engineering: the systems that last are the ones built with restraint. Not the ones with the most features, the cleverest abstractions, or the most comprehensive test suites — but the ones where someone said “no” more often than “yes.”
The cost of complexity
Every abstraction has a maintenance cost. Every indirection adds cognitive load. Every configuration option is a decision someone will have to make — or worse, a decision that will be made by default and never revisited.
The question isn’t “can we add this?” but “what happens when we do?”
A practical heuristic
Before adding a feature, ask: if this system had to be understood by someone in five years with no documentation beyond the code itself, would this addition help or hinder?
Most of the time, the answer is clear.
What simple actually means
Simple doesn’t mean trivial. It means:
- Few concepts — each one pulling its weight
- Explicit over implicit — no magic, no surprises
- Deletable — any part can be removed without understanding the whole
The best code is the code you don’t have to read to understand the system.