Thinking about performance prematurely
2026-09-21T08:30:00.000Z
It’s easier to optimise a working system than to debug a fast one.
Over the years I’ve heard colleagues worry about performance very early in the life-cycle of a project. Questions like:
- How fast will the system be?
- Will it scale?
- Is it efficient enough?
Those are not unreasonable questions. But I’ve often thought we ask them at the wrong time. A phrase I once heard captures the sentiment really well:
“It’s easier to make a working system go fast than a fast system work.”
Getting the system to behave correctly is, IMO, usually the hard part. Understanding the requirements, handling edge cases, defining interfaces and architecture, defining how components interact, and finally building something the software team can reason about. That’s where most projects struggle.
Once the system works and its behaviour is clear, performance issues are usually surprisingly easy to address. You can measure, profile and change specific pieces with confidence.
And at the code level, there’s another reason I’m wary of optimising prematurely. Modern compilers are really good at many of the low-level optimisations humans used to perform manually. The optimisations humans are good at are usually much higher level: picking the right algorithm, container, architecture or pattern. These decisions matter more than trying to outsmart the compiler with clever code.
When performance concerns dominate the design too early the result is often the opposite of what was intended. The system and code become harder to understand, harder to change and much harder to debug, precisely when its behaviour is still evolving.
Of course there are always exceptions. Some software systems have hard real-time constraints or very limited resources, and they must shape the architecture from the start.
But in many projects, especially complex software systems, clarity and correctness are the real challenges and not raw performance.
In my experience the most reliable sequence is still:
- Make it work.
- Make it clear.
- Then make it fast (if it isn’t already fast enough).
Because optimisation works best when the system is already understandable.