Kristofer Palmvik.

I find myself constantly asking my colleagues: do we really need this?

Do we really need to support this unique case? Do we still need this custom API? Do we need to use this complicated technology?


Software systems love complexity.

Give engineers a problem, and they'll likely build you a solution that could handle just about anything.

An important customer's request could lead to a special solution, allowing similar things to be done in several ways.

Flexibility sounds great. Who doesn't want a system that can do anything? But unfortunately this isn't free.

Every abstraction, every special case, every "what if" scenario adds cognitive overhead. Developers spend more and more time understanding the existing system instead of actually improving it.

The real skill is knowing where the flexibility matters, and where it is just overhead.

Don’t make everything flexible. Limit it to the places where you really expect things to change.

Let’s say you sell books.
Supporting both paper and audio books? Seems reasonable.
Designing a system that could theoretically handle all types of documents, including stone tablets and ancient manuscripts? That is probably just making things complicated.

The key is to tie the capabilities to the overall strategy of the product and company.

What's likely to change?
What’s likely to be static?
Where is the uncertainty?

A good system isn't one that can do everything. It's one that does the important things clearly, and can be changed easily enough.

So whenever I see something that might not make sense I’ll keep asking: Do we really need this?

Do we really need this? was first published 2024‑11‑28