When the right engineering decision is to build less

Product design wireframe, photo by Alvaro Reyes on Unsplash

There is something satisfying about solving a complicated technical problem.

There is something even more satisfying about realising you do not need to create it in the first place.

Complexity can arrive disguised as completeness

When a feature is being shaped, it is easy to keep adding. More configuration. Another state. Another abstraction in case we need it later. A workflow flexible enough to handle scenarios nobody has actually asked for yet.

Each addition can sound individually reasonable. Together they create a system somebody has to understand, test, monitor and change.

I’ve become much more interested in asking what we can leave out.

Start with the outcome

The easiest way I’ve found to simplify technical work is to get clearer about the product outcome. What does the person actually need to achieve? Which part is essential now? Which part are we designing because it might theoretically be useful one day?

That does not mean always choosing the quickest implementation. Sometimes investing in the right foundation now avoids a painful constraint later. The skill is recognising the difference between deliberate foundations and speculative complexity.

Simple does not mean careless

A smaller solution still needs to be reliable. It still needs sensible failure behaviour, permissions, tests and enough observability that we can understand it in production.

In fact, reducing unnecessary moving parts often gives us more room to do those things well.

Code has a cost after it ships

Every abstraction becomes something a future engineer has to learn. Every option becomes another path to test. Every new service, event or configuration point becomes part of the mental model of the system.

That is why I don’t think “less” is anti-engineering. Often it requires more judgement. You have to understand the problem well enough to know what can safely disappear.

Some of the best technical decisions do not leave behind an impressive amount of code. They leave behind a product that does what it needs to do and a system the next person can still understand.

← Back to writing