What “Software Done Right” Actually Means

We put three words at the top of everything we make: software done right. It is short enough to fit on a business card and demanding enough to argue about in code review. So it is worth being precise about what each word is carrying.

Software

Software is not the feature list. It is the thing that runs at 3am when nobody is watching, that a teammate inherits two years from now, that a customer leans on without ever thinking about it. We treat the artifact — the code, the schema, the deploy — as the deliverable, not the demo.

That framing changes small decisions constantly. A function gets a name that survives being read out of context. An error path gets handled instead of swallowed. A migration gets a way back. None of it shows up in a screenshot. All of it shows up six months later.

Done

"Done" is the word people quietly negotiate away. It starts meaning finished and drifts toward demoed, then merged, then technically shipped. We try to hold the line:

• It handles the unhappy paths, not just the golden one.
• It fails loudly and recoverably, never silently.
• Someone other than the author can run it, read it, and change it.
• The thing it replaced is actually gone, not left to rot beside it.

If those aren't true, it isn't done — it's in progress wearing a deploy.

Right

"Right" is the contested one, because it implies there is a wrong, and saying so out loud costs something. We think the wrong version is usually the one optimized for the wrong horizon: fast to merge, slow to live with.

The cheapest code to write is almost never the cheapest code to own.

Right means the second engineer is faster than the first, not slower. It means the boring choice when boring is load-bearing, and the bold choice only where boldness actually buys something. It means we'd be comfortable being the ones on call for it — which, often enough, we are.

Three words. We say them constantly, because the moment a standard stops getting repeated is the moment it starts bending.