The Difference Between Shipping and Finishing

A carpenter I knew had a habit that irritated his apprentices. After a piece was assembled and functional and, by any reasonable account, done, he would spend another hour on it. Running a hand along an edge. Adjusting something nobody would ever see. When asked what he was doing, he said he was finishing it, in a tone that suggested this was self-evident and slightly beneath discussion.

The pieces he made are still in use. I have thought about that hour more than almost anything else I learned in that period, because it named a distinction I had been missing. The work had been complete for an hour before it was finished, and the difference was invisible to everyone except the person who would live with it.

Complete means it works. Finished means someone decided it was good.

Shipping is a decision about time

Shipping is an event. A moment arrives, somebody decides the thing should go out, and it goes out. It can happen at any level of quality — this is the important part — because nothing about the act of shipping requires the work to be in any particular state.

This is why shipping culture, taken alone, produces such uneven results. Ship early and often is good advice against the specific disease of endless polishing in private. As a total philosophy it is empty, because it says nothing about what to ship, and a team that internalizes only that instruction will reliably produce a stream of things that were released rather than made.

Finishing is not an event. It is a state the work reaches, and it can be described independently of any date: the edges are handled, the failures are graceful, the language is right, the thing behaves sensibly when used in ways you did not plan. Work can be shipped without reaching that state. It usually is.

Where the last ten percent lives

It is worth being concrete about what finishing actually consists of, because described abstractly it sounds like perfectionism and it is not.

It is the empty state, which every product has and almost none design. It is what happens on a slow connection, at three in the morning, on a phone with a cracked screen. It is the error message rewritten until a tired person could act on it without a support ticket. It is the second visit, which nobody tests because everyone tests the first. It is the loaded state, three years in, when there are eleven hundred items and the layout was designed for eight.

None of these appear in a demo. All of them appear in a life with the product. That is the whole asymmetry: the parts that determine whether something is good to live with are precisely the parts that are invisible when it is being evaluated.

The trap on either side

There are two failures here and I want to be fair to both, because the correction for one is the cause of the other.

The first is shipping without finishing. It produces a large body of work that nobody quite loves, a growing maintenance burden, and a slow erosion of the team's belief that quality is achievable here. People stop trying, not out of laziness, but because trying has stopped being rewarded.

The second is finishing without shipping. This one wears the costume of high standards and is usually fear. Work that never goes out never gets judged. The refinement is real refinement, but past a point it stops improving the thing and starts protecting the maker, and the tell is that the person cannot say what would make it ready.

The resolution is not a midpoint. It is a change of scope. Choose less, and finish what you chose. A small thing, genuinely finished, ships on time and is better than a large thing released in pieces. Most teams solve the tension by lowering quality across a wide surface, when the available move was to narrow the surface and keep the quality.

The answer to too much work at too high a standard is less work, not a lower standard.

Knowing when it is finished

The practical difficulty is that finishing has no natural signal. Complete has one — it works. Finished must be defined, in advance, by a person willing to say what good means for this particular piece of work.

So I write it down before starting. Not a task list; a description of the state. What flows must be solid. What the first session should feel like. Which edge cases are handled and which are explicitly out of scope for now, named so they are decisions rather than oversights. That last category is what makes the practice sustainable — finishing does not mean handling everything, it means having chosen what to handle and being honest about the rest.

With that written, the question at the end is answerable. Not by feel, not by exhaustion, not by the calendar, but by comparison against a standard someone set while they were still thinking clearly.

Why the hour matters

The reason I keep returning to that carpenter is that his extra hour was economically irrational in the short run and obviously correct in the long one. Nobody paid him for it. Nobody would have noticed its absence at the moment of delivery. They noticed it in year fifteen, and they told other people, and that is where his work came from.

Reputation is built almost entirely in that hour. Everything up to it is table stakes; anyone can make a thing that works. The willingness to spend unpaid, unwitnessed time bringing something from complete to finished is rare enough that it functions as a strategy, which is a slightly cynical way of describing what is really just caring about the work.

Ship, certainly. Ship earlier than is comfortable. But know the difference between the day it went out and the day it was done, and try to keep those two dates closer together than most people bother to.

If you have something that works and does not yet feel finished, that last stretch is my favorite part of the work. I would enjoy hearing about it.