Make it work, make it right, make it fast

Get the thing running end to end, however rough, before worrying about anything else. A rough version that works shows you what the real problems are and brings up edge cases you'd never spot on a whiteboard.

Until it works, any other effort is guesswork.

Once it works and you've seen where it struggles, tidy it up: the structure, the naming, the edge cases and the bad inputs. Quality comes from this deliberate second pass, taken after you've seen what matters in practice.

Code that's made "right" before it works is usually right about the wrong things.

Only now is it worth optimising. Performance work is tempting because it feels rigorous, but speeding up code before it works, or before it has the right shape, is the most common waste in engineering.

Most of the time, correct code is fast enough. When it isn't, you have a working, well-structured system to profile, so you can fix the part that needs it.

Get it correct before you make it elegant, and elegant before you make it fast.

Done in order, each step makes the next one easier. Done out of order, you end up polishing and optimising work that gets thrown away.

This is a delivery principle the whole team can share, as well as advice for individual engineers. It gives everyone a common way to judge whether something is done, and it guards against two expensive habits in software: gold-plating and premature optimisation.

When a team follows the order without being reminded, code reviews improve, estimates get more realistic and work gets built when it's needed.