Why good software should often do less

There is a surprisingly reliable way to make software gradually worse: keep adding features.

At first, that sounds contradictory. After all, a new feature is a good thing. It solves a problem, covers an edge case or fulfils a wish that somebody once expressed. And that is exactly why saying no is so difficult.

The problem begins when many good individual decisions add up to a poor overall product.

An application can have a hundred useful features and still feel unpleasant. It can be technically impressive while overwhelming its user with dialogues, options, switches and submenus. It can do almost everything and be annoying in everyday use precisely because of that.

To me, good software is therefore defined by doing the right things and making them feel natural, rather than by doing as much as possible.

Every feature has ongoing costs

When developers discuss new features, they often start with the effort needed to implement them.

How long will development take? Which classes do we need? Does the data model need extending? What tests will we add?

These are important questions. But they do not go far enough.

A feature does not only cost something during development. It stays in the product.

It needs a place in the interface. It needs documentation. It needs testing. It may interact with other features. It creates new states, new failure cases and, eventually, new questions.

Above all, it costs attention.

An additional button does more than take up twenty or thirty pixels. It is another decision the user has to make.

Do I need this? What happens if I click it? Is this the right approach, or is there an even better feature somewhere else?

With ten features, you barely notice. With a hundred, you do.

Flexibility does not automatically mean usability

As a developer, it is tempting to make software as flexible as possible.

Why offer only three options when you could offer twelve?

Why choose a sensible default when you can leave the decision to the user?

Why provide a defined workflow when everything can be configured?

Technically, this often seems elegant. From a user’s perspective, it can be exhausting.

One example is a file renaming tool. Of course, you could offer every imaginable transformation as a separate option. Prefixes, suffixes, counters, regular expressions, dates, character replacements, scripts and much more.

The challenge is not programming these possibilities. The real challenge is arranging them so that somebody who simply wants to rename twenty photos does not feel as if they have to learn a small programming language.

This is exactly where feature range and product quality part ways.

Good software makes decisions

I believe a large part of good product development is taking decisions off the user’s hands.

Not in a patronising way. In a sensible one.

If a setting is right in ninety per cent of cases, it should probably be the default.

If very few people need a feature, perhaps it does not need a prominent place in the main window.

If two options do almost the same thing, it is worth considering whether both are really necessary.

That sounds obvious, but it is surprisingly difficult.

During development, leaving things out can quickly feel like giving away possibilities. In reality, you often gain something much more valuable: clarity.

The main screen is not a storage room

There is an effect in interface design that is probably familiar to anyone who has worked on a product for a while.

At the beginning, there is plenty of space.

Then a feature is added. And another. There is room for one more button somewhere. A small group could go on the right. There is still space at the bottom too.

A few months later, the main screen looks like the tool trolley of a very enthusiastic DIY enthusiast.

Everything has a reason to be there. Nothing can go. And nobody can find the screwdriver at first glance any more.

That is why I now try to think more in layers when designing interfaces.

What do people need all the time? That belongs up front, clearly visible.

What do they need occasionally? That can be one step away.

What is an expert feature? It can exist without waving at every user on first launch.

A good interface does not show everything an application can do. It first shows what is likely to be needed at that moment.

Less does not mean simplistic

There is a distinction that matters to me here.

Software with a clear interface need not be simple internally.

Quite the opposite.

A particularly large amount of work often lies behind an easy-to-use interface. The application needs to choose sensible defaults, detect errors, consider dependencies and handle edge cases.

Ideally, the user sees little of this.

It is a bit like a good lift. Nobody wants a configuration page for acceleration, door timings and motor control before taking a ride. You want to press a button and arrive on another floor.

In software, we forget this principle surprisingly often.

Removing features is harder than building them

A new feature is relatively easy to justify.

Somebody wants it. A competitor has it. It sounds interesting.

Removing an existing feature is more uncomfortable.

Perhaps somebody uses it. Perhaps that very person will complain. Perhaps it will be needed again later after all.

That is why software often grows almost automatically.

I now consider it at least as important to think regularly about the opposite:

Which feature is barely relevant any more?

Which setting exists only for historical reasons?

Which two paths could be merged into one?

Which dialogue could disappear because the application can make a sensible decision itself?

These questions are less spectacular than a new feature. They are often more important to a product’s quality.

I have to remind myself too

The interesting thing is that even knowing these principles does not make you immune.

When I work on my own software, I regularly catch myself thinking: we could add that too.

The idea might even be technically appealing.

Then a different question helps:

Does this feature really make the program better for the user, or does it mainly make the feature list longer?

That is not always easy to answer.

Sometimes, of course, the answer is yes. Software is supposed to solve problems, and that requires features.

But a good product decision does not end with the question of whether something is possible.

It begins there.

The best feature may be one nobody notices

Some of the most pleasant qualities of good software never appear in a big feature list.

An application remembers the last useful state.

It prevents an invalid action before an error message becomes necessary.

It suggests a workable default.

It shows the right information at the right moment.

It does not force me to configure something it could know itself.

These things are hard to sell because they sound unspectacular.

But they make an enormous difference in everyday work.

Perhaps that is even a useful measure of good software:

How little I have to think about operating it, rather than how many things it lets me do.

Less is not a religion

Of course, turning this into a dogma would be nonsense.

A professional tool is allowed to be complex. A file manager, a development environment or an image editor needs more capabilities than a calculator.

So the question is not: how do we get as few features as possible?

The better question is:

How much complexity does the task actually require, and how much of it do we need to impose on the user?

That is a big difference.

Complexity cannot always be avoided. But you can decide where it becomes visible.

Good software respects attention

In the end, for me this is about something that comes up surprisingly rarely in technical discussions: attention.

People generally do not use software because they want to use software.

They want to write an invoice, organise files, edit an image, create a QR code or complete some other task.

The application is a means to an end.

Good software respects that.

It does not constantly try to prove how powerful it is. It does not needlessly push itself to the foreground. It helps, then steps out of your thoughts again.

Perhaps that is exactly why good software should sometimes do less.

Not because less is inherently better.

But because every feature has to earn its place.