Better Isn't Always Better

Engineers are trained to improve things. Show us a system that is slower, clumsier or less elegant than it could be, and we itch to fix it. Most of the time that instinct is right, and the world is quietly better for it.

Occasionally it walks us straight into a trap.

You ship the improvement — genuinely better, measurably better, better by every number you could put on a slide — and the users are furious.

The first time it happens, it is baffling. You have handed someone a sharper tool and they are cross that you took away their blunt one. Surely they can see it is better?

They can. That is not the problem. The problem is that “better” was measured on the wrong axis.

I would like to claim this insight as my own. I cannot. It was handed to me by a very wise CEO, mid-conversation about why people resist change, and it quietly rearranged how I think about the whole subject: better is not always better. I have been grateful for it — and occasionally humbled by it — ever since.

The thing you improved was not the whole system

When people use a system for long enough, they stop using its features and start using their memory of it. They know the number they need lives in the third column, slightly wonky, next to the thing that is mislabelled. They know which figures to trust and which to quietly ignore. They have built, at real cost, a mental model precise enough to make fast, confident decisions.

That fluency is written down nowhere. It does not appear in the codebase. But it is absolutely part of the system — arguably the most valuable part, because it is where the decisions actually get made.

When you “improve” the interface, you polish the half you can see and quietly demolish the half you cannot. The tool got better. The user got worse, overnight, at their own job. On the day you ship, the net effect can be a real, measurable step backwards — even though the new thing genuinely is better.

An example that still stings

I once tidied up a reporting screen that was, frankly, a mess: cluttered, inconsistent, badly aligned. I made it clean, logical and consistent, and I was rather pleased with myself.

The operations team reacted as though I had rearranged their kitchen while they were holding hot pans. It turned out they read the old, ugly screen at a glance — the very clutter I had removed was how they navigated it, the messy grouping was their map. My elegant new layout was, to them, a familiar city with all the street signs swapped overnight. For weeks they were slower and less certain, and every mistake was, fairly, mine.

The redesign was better. It was also, for a while, worse. Both were true at once, which is the whole uncomfortable point.

Familiarity has momentum

There is a name for this quiet drag: path dependence — the idea that where you can usefully go next is shaped by the road you have already travelled. A system everyone knows deeply has momentum. It carries decisions forward efficiently precisely because nobody has to think about the tool any more; they can spend all their attention on the actual problem.

A better system, freshly landed, has none of that. It demands the attention back. Every improvement carries a switching cost, and the awkward thing about switching costs is who pays them. The benefit usually arrives later, spread thinly across everyone. The cost — relearning, lost fluency, a fresh crop of mistakes — is paid now, by the specific people you were trying to help. From where they stand, you have taxed them today to reward someone else tomorrow.

They are not being irrational. They are doing an accounting you forgot to do.

Resistance to change is sometimes just wisdom in a bad mood

Engineers have a habit of filing all resistance under “conservatism” and pressing on regardless. Sometimes that is the right call. But much of what we dismiss as stubbornness is a rational refusal to swap a system people can trust for one they cannot yet.

Trust is earned slowly and reset instantly. A predictable tool you understand — faults and all — is often more useful than a superior one whose failure modes you have not learned. “Better the devil you know” is not cowardice. It is risk management, done by the people who will personally carry the risk.

But not all of it

I should be honest, because this argument has a comfortable failure mode of its own.

Taken too far, “respect familiarity” becomes a licence to change nothing, ever. Every organisation has a creaking system that everyone has heroically adapted to, that is quietly costing a fortune, and that is defended with precisely the arguments above. Some resistance really is just the discomfort of the first week mistaken for a principle — the kind that evaporates the moment people stop mourning their old shortcuts.

So the real skill is telling the two apart. Is this the rational cost of discarding genuine, hard-won fluency? Or is it the ordinary friction of learning, which will fade by Friday? The first should change your plans. The second deserves patience, a decent migration, and a bit of nerve.

What “better” should actually mean

The lesson I took was not “stop improving things”. It is that an improvement has to be better by enough to outweigh what it destroys — and that what it destroys is usually invisible on the spec sheet.

Which changed how I ship. Improve gradually where you can. Keep the old path alive while the new one earns its trust. Let people opt in before you opt them in. Explain the why, not just the what. And occasionally reach the genuinely grown-up conclusion: this is better, and we are still not going to do it, because it is not better by enough.

Better on paper is not the same as better in someone’s hands. The user’s fluency is part of the very system you are so keen to improve. An improvement that ignores it is not really an improvement.

It is just change, wearing improvement’s badge.

• #thinking
• #engineering
• #user-experience
• #change

@online{byatt2026-betterisntalwaysbetter,
  author  = {Stephen Byatt},
  title   = {Better Isn't Always Better},
  year    = {2026},
  date    = {2026-02-05},
  url     = {https://learningoutloud.stephenbyatt.com/blog/better-isnt-always-better/},
  urldate = {2026-02-05},
  note    = {Learning Out Loud}
}