UDEHA
Judgement

Premature optimisation

Polishing something before you know it matters — effort spent on a constraint you do not have yet.

Premature optimisation is improving something before there is evidence it is worth improving: building for a load you have never seen, designing a brand for a business with four customers, automating a process that runs twice a month.

The reason it is so common is that it feels exactly like diligence. The work is real, it is visible, and it produces something you can show. What separates it from useful work is the absence of a measured constraint: you are optimising a step that nothing is queuing behind. Meanwhile the actual constraint — usually a conversation you have not had or a thing you have not shipped — is uncomfortable, unmeasurable and easy to defer.

There is a legitimate exception, and it is worth naming so the idea is not used as an excuse to build carelessly: things that are expensive to change later, such as data you will not be able to recover or a promise made publicly, deserve care up front. Everything else earns its polish by being used.

Worked: three weeks building an admin panel for a workflow run once a week. Done by hand it costs 20 minutes a week — about 17 hours a year. The build cost 120 hours and pays back in seven years, by which time the workflow will have changed twice.

Also known as

  • over-engineering
  • gold-plating

Relevant for

Founders
It feels exactly like diligence, which is why it wins: you are speeding up a step nothing is queuing behind, while the real constraint is a conversation you are avoiding.
Creators
The new setup, the redesign and the better tool are all work you can show — none of them is the thing you have not published.

Read more in the Library