The Last Human Before Production

Suppose you spend a Tuesday morning deciding what a refund is. Whether the clock starts when you dispatch it or when the customer signs for it, what a partial return does to the clock, whether a replacement resets it. By eleven you’ve written the answers down, and that’s the last decision a person makes about this feature.

Everything after that is machinery. One station turns your rules into checks, and the next writes code until the checks pass. Reviewers go over the result against the standards. On Friday a release goes out with its parts list attached.

Somebody approves that release. They’re the first person in the whole run to see the software do anything, because everyone before them was reading a description of it.

That’s the trouble with the gate at the end. By the time anyone gets a real look, every decision was made days ago.

The gate at the end

If you’ve put a person anywhere in a line like that, it’s probably at the deploy. Someone senior looks at what’s about to go out and approves it. That makes it the last door before the customer, so it feels like the right door to stand in.

You didn’t choose that gate. It comes from a line where every step between the rules and the release was done by a person, and any of them could stop and ask. The developer read the ticket and thought the requirement was odd. The reviewer had seen this go wrong before. If the approver at the end had a question, there was someone to ask.

Take them out and the approver is looking at a change that was settled in full by a document written days earlier. They can read it and they cannot ask why it’s like that, because the answer is that the rules said so.

Which is why the late gate survives in lines built by people who know all this, mine included. So the question is what it’s for, and what has to happen earlier.

Two decisions, not one

Go back to Tuesday. You made two different kinds of decision that morning, and they don’t belong in the same place.

The first is the number. Thirty days, and the clock starts at delivery. That’s what correct is for this feature. Every check written downstream asserts it, the code satisfies the checks, the reviewers confirm the change matches, and if the business has always run the clock from dispatch then nothing after Tuesday catches it. Nothing failed, no gate was skipped, and the line carried out a wrong definition perfectly.

The second decision is quieter. What is delivery. Is it a moment, or a state the order sits in, and does a replacement deliver twice. Those answers don’t describe the refund feature. They constrain everything that ever touches delivery.

Get the number wrong and you ship one wrong feature. Get delivery wrong and every test, every implementation and every future change in that part of the system inherits it. Same morning, same person, and the second mistake costs an order of magnitude more to unpick.

My own line gates both. The scenarios get a human review before any architecture work starts, and the domain model, the document that settles what the words mean, gets another one before anything is built from it. Two gates. One fixes the behaviour, the other fixes the language.

The domain check goes last, and after it nobody in the line has a decision left to make.

Stopping is not alerting

Putting people early only works if the line can’t run past them.

At the speed the line moves, an alert is a record that something has already happened, and the window between a problem and its consequences closes before anyone can cross it. That was true of watching a system in production. It’s worse here, because what comes out is finished work, not warnings.

An upstream gate holds because nothing starts until it’s signed. Nobody has to be watching.

The same has to be true when a station gets stuck halfway through. One that can’t satisfy the rules it was given can interpret them, or it can wait. Interpreting is faster, looks like progress and passes every check downstream, because the checks came from the same ambiguous source. So build the line so the work stops and waits for a named person rather than a channel. Otherwise it’s a notification.

What the late gate is for

Which leaves the approver on Friday, seeing the software work for the first time.

Requirements engineering split this in two a long time ago. Verification asks whether you built the product right, and validation asks whether you built the right product. An automated line verifies and does nothing else. Every station after the scenarios checks the software against a definition, and passing that check is the whole job. Validating means going back to whether the definition was what anyone wanted, and no station does that.

So validation happens once, on Friday, at the latest possible moment.

Boehm measured what that costs at TRW in the 1970s and published it in 1981. The price of fixing something climbs at every stage between requirements and production. How steep the climb is has been argued over ever since, and he found it far flatter on small projects than on large ones. The direction has held for forty-five years.

Keep the approver. Stop calling it control. A gate stops a line, and Friday is where you find out.

What they find is a validation failure, and validation has a home three days upstream. Fix it in the change and the same wrong definition ships again next month, because nothing that produced it moved.

The review before merge was always doing two jobs, checking the work and being the first sight of the software. People did the checking. Machines do it now, and nobody moved the meeting. The button is still there and what it means changed underneath it.

What the job becomes

The usual answer to where humans belong is a list of qualities: taste, judgement, deciding what to build. All of it is true and none of it tells you where to stand on a Tuesday morning. A job description isn’t an architecture.

If what the line ships is set by the definitions it was handed, the scarce skill is whoever can write them and be right. That work is smaller than the job it replaces and harder than it sounds. A few hours deciding what a word means, with nobody left to catch you, because everything downstream now agrees with you.

Senior engineering hours still go on pull requests, which is where they went when a pull request was the last place a person could change their mind. That point moved earlier and the budget stayed where it was. You can hire a reviewer. There’s no job title for the person who decides what delivery means, so the money goes to the role that has one.

Closing

Nobody left the line. Two moved to the front, where the numbers and the words get settled, and one stayed at the back to watch the software run. Only the two at the front can still change their mind.

Sources

• Guidelines for Verifying and Validating Software Requirements and Design Specifications, Barry Boehm, Euro IFIP 79, North-Holland, 1979. Source for the split this piece turns on, and for the formulation usually credited to it: verification asks whether you built the product right, validation whether you built the right product.
• Software Engineering Economics, Barry Boehm, Prentice Hall, 1981. Source for the cost of fixing something climbing at each stage between requirements and production, from data collected at TRW with corroborating figures from IBM, GTE and the Bell Labs Safeguard programme, first presented in 1976. Boehm also records the curve running far flatter on small projects than on large ones, which is why this piece claims a direction and not a multiple.
• The Leprechauns of Software Engineering, Laurent Bossavit, Leanpub, 2015. The case against the numbers everyone quotes. The famous hundred-times table is not Boehm’s, it belongs to an “IBM Systems Sciences Institute” that published no study, and the trail runs back through a textbook to internal course notes. Read before citing any figure from this area.
• ISO/IEC/IEEE 29148:2018, Systems and software engineering, Life cycle processes, Requirements engineering, ISO, 2018. Source for requirements engineering as a named discipline, with elicitation, analysis, validation and verification treated as separate activities with separate owners.

Related reading (Synaptic Pixels)

• The Disciplines AI Governance Forgot, on the disciplines that already solved these problems and did not transfer, and on blast radius as a design constraint.
• From Human Supervision to Policy Governance, on supervision having latency at machine speed.
• When Humans Leave the Loop, on the informal human work a line removes when the people go.
• The Software Factory You Didn’t Notice You’d Built, on loops composing into a line nobody designed, and the open question this piece answers.
• Where Does Your Dark Factory Stop?, on what the line can reach and why you cannot read it off the code.