On Minimalism in Software

There is a certain pleasure in software that does one thing well.

Not because complexity is inherently bad — some problems are genuinely complex and deserve complex solutions. But most problems aren’t. And most software accretes complexity not because the problem requires it, but because it’s easier to add than to remove.

The cost of features

Every feature a piece of software has is a feature that must be:

• Designed
• Implemented
• Tested
• Documented
• Maintained
• Understood by the user

The last item is the one we most often forget. A feature that confuses users is worse than no feature at all, because it occupies mental space without providing value.

What minimalism actually means

Minimalism in software isn’t about having fewer lines of code, or a smaller bundle size, or fewer dependencies (though those are often useful side effects). It’s about having fewer concepts — fewer things the user has to understand to accomplish their goal.

A minimal interface is one where the user’s mental model and the software’s model are the same thing. When they diverge, friction appears.

The refactoring that never happens

The problem with complexity is that it compounds. Adding a feature to a simple system is easy. Adding a feature to a complex system requires understanding the existing complexity first, which is expensive, which makes each new feature more likely to add yet more complexity rather than integrate cleanly.

The refactoring that would restore simplicity keeps getting deferred — it’s never the most urgent thing, until suddenly the system is incomprehensible to everyone including the people who built it.

---

I don’t have a prescription for how to avoid this. I just find myself increasingly drawn to things that are simple. And increasingly suspicious of things that aren’t.