The right moment: technical judgment and shipping speed

Two deliveries in the same month, from the same pair of hands, on opposite criteria.

The first was a landing page for a three-day trade fair. Two afternoons, no tests, copy pasted straight into the HTML, a form that sent an email. It did the job, the fair ended, the page was deleted. It was a good technical decision.

The second was the billing data model for a small client. It slipped a whole week over how to store a credit-note line, with the client waiting and the permanent feeling of wasting time on something nobody could see. That model hasn’t been touched in three years.

Counted in speed, one was blazing and the other glacial. Counted that way none of it makes sense, because speed wasn’t the variable.

Two words for time

Greek had two. One is measured time (chronos): days left, sprint hours, the date of the fair. The other is the opportune moment (kairos), the instant in which an action makes sense and outside of which the same action doesn’t.

Almost every conversation about shipping uses the first and needs the second. “Can we have it by Friday?” asks about measured time. “Is this the moment to decide this?” asks about the opportune moment, and it’s the question that determines whether Friday will be worth anything.

A board measures the first one beautifully. It has no column for the second.

Isocrates made a living from this

Isocrates opened a school in Athens and spent fifty years in an awkward position, with enemies on both sides. Facing him were the sophists promising a method to argue anything, and facing him was Plato, after a science of what doesn’t change. He held something more modest and much harder to sell: that about human affairs there is no exact knowledge, and that the educated person is the one who hits on what is fitting most of the time.

His most honest part was the one that helped his business least. He taught the forms of discourse — that much can be handed over, he said — but warned that choosing which one fits each occasion, mixing them and ordering them, is covered by no art. That part the student supplies, or nobody does. He sold training while admitting in writing that the deciding part can’t be taught.

Anyone who has tried to explain to someone less experienced why here yes and there no recognises the whole problem.

What actually gets decided

The useful question isn’t how much rigour I apply. It’s when does this stop being cheap.

Some decisions have a moment that comes once and doesn’t return. The shape of the table is decided the day the first row is written; after that you aren’t deciding, you’re migrating. The identifier that goes public is decided before anyone links to it; afterwards, changing it is an amputation. The contract of a public API is decided before the second consumer exists. In all of them, the week spent on the credit note is cheap: it’s the only stretch in which the decision still costs what thinking about it costs.

And some decisions have no moment yet. The abstraction of a flow you’ve seen once. The admin panel for content nobody edits. The message queue for a system with nine users. Bringing those forward isn’t rigour: it’s answering a question nobody has asked, and committing to the answer.

Deciding too early and deciding too late are the same mistake with two faces. One is paid in abstractions that guessed wrong; the other, in migrations.

“Technical debt” is a bad name

The accounting metaphor suggests somebody borrowed knowingly and will repay with interest. It’s almost never what happened. What usually happened is that a decision was made at the wrong moment, and there are two different ways of getting that wrong that the word “debt” throws into one bag.

That’s also why “we’ll clean this up later” almost never happens. It isn’t that people lie. It’s that the cleanup gets scheduled in measured time — “next sprint” — and its moment was the opportune one: it was the stretch while you still had the whole problem in your head, before the context cooled and three things came to rest on top of it. That stretch passed, and next sprint the same task no longer costs the same.

With one exception worth saying out loud, because it gets used as an alibi for the opposite. An incident at three in the morning is the moment for the patch and is not the moment for the redesign. Both moments are real and they are different. The failure of craft isn’t applying the patch: it’s never coming back for the second moment, which existed, and which was Tuesday morning with the incident still fresh.

The questions I ask now

They replaced the list of “when speed wins”, which never once helped me in front of an actual case.

• Can this be undone, and at what cost? It’s the only question that really separates the two families. What’s reversible gets decided fast and corrected. What’s irreversible gets decided slowly, however loud the calendar.
• Who links to this from outside? If the answer includes anyone I don’t control — a search engine, a client’s invoice, another team — the moment to think about it is now and there won’t be another.
• How many times will we touch this file next year? It’s the old question and it still holds. Only now I read it as a question about timing: if the answer is “many”, every week that passes makes thinking about it dearer.
• Is the hurry the business’s or mine? There are real urgencies — a dated campaign, a fiscal close, a payment gateway down — and there’s a professional impatience that dresses up as them. The first one rules. The second is what makes you see deadlines where there is only an eagerness to see the thing running.

Hurry isn’t speed

The distinction I use most isn’t philosophical and stands on its own: hurry and speed are not the same thing.

Speed is arriving in the time it takes without wasting steps. Hurry is skipping steps to arrive sooner and finding out afterwards that you’ve arrived somewhere else. A fast team ships quickly and the next change costs the same or less. A hurried team ships quickly and the next change costs double, in a quarter where nobody remembers why.

In the button I didn’t build the subject was what gets implemented. This is the subject next door and the two get confused often: not what, but when. You can be dead right about the feature and completely wrong about the moment you decided its shape.

Isocrates left no method, and not for want of trying: he left it in writing that there wasn’t one. What he left was the idea that judgment about the occasion is educated — by deliberating, shipping and getting it wrong — and that anyone selling it as a rule is selling something else. After a fair few projects, the only rule that has held for me is asking, before accelerating, whether what’s in front of me can still be undone.