# Making it simple is a technical achievement
The craft · principle · https://build-here.africa/book/chapters/02-01-making-it-simple-is-a-technical-achievement.html

## The reflex

A solution piles up options to cover every case imagined. Each one looks reasonable on its own. Together, they make the work heavy for everyone.

## The builder's reflex

> "What do people actually need here, and which part adds cost without helping them?"

## Why

Adding is easy: every option answers a request, every field a case. Removing takes understanding. That is why making it simple is an achievement: you have to know exactly what each part does before you dare take it out.

One form loses a useless field and gets quicker to fill in. Another loses the field accounting needed, and the problem comes back three weeks later, somewhere else. The difference between the two is the question asked first: who uses this information, and at which next step?

A rare case can be protecting an important operation. Absent this week, it can happen next week. Before you remove something, ask whoever maintains it what it has already prevented.

This holds for a screen, a procedure, a report, a sales offer or a dashboard. The simple version keeps what makes the work right and removes what makes it harder. Nothing more, nothing less.

## Try this

Pick a part of your work you can explain. Write down what you would like to remove and what that part makes possible today.

Show it to someone who uses it. Then remove it on a small scope, keeping what you need to put it back.

After one cycle of use, see whether the task got easier and whether something is missing. Keep, adapt, or put it back.

## To discuss

Which recent simplification reduced the effort while keeping the service intact?

*Check it elsewhere:* Rich Hickey examines the distinction between simple and easy in *Simple Made Easy*, cited in *[Already written](/already-written/)*.