Nine pull requests, shipped one after another over about a week. When I finally looked at what actually depended on what, only three of them had a real dependency. The other six were sequential because a person can only type one thing at a time.
Twelve layers of work collapsed to five. Same code, same order of operations where it mattered, roughly half the wall clock.
I want to be precise about what went wrong there, because it was not a failure of planning. I had planned. I had done the whole thing we have spent this series arguing for: tickets first, plan accepted as a separate act from go, the lot.
What I had written down was a list.
A list records the order things occurred to me. A graph records the order they actually depend on each other. They look identical on the page, and you cannot tell them apart by reading, because a list of nine items and a graph of nine items are the same nine lines. You have to ask, item by item, what this one is genuinely waiting for. Most of the time the honest answer is nothing.
Plan twice, execute once
I learned measure twice, cut once building houses, long before any of this, and it stuck because I was the cutter. The person holding the tape can afford to be casual. The person at the saw cannot, because the offcut does not go back on.
We treated it as sacrosanct. That is the same word I reached for years later about tickets, and I do not think that is an accident.
Plan twice, execute once is the same rule moved indoors. Whether I transposed it deliberately or simply carried the habit across, I could not tell you. Either way it is what I do. The first pass is raw: what are we building, broken into shippable pieces. The second pass goes back over the same material asking a different question: how does this actually fit together.
Until recently the second pass was instinct and a pencil.
What the graph people were describing
In late July, Anatoli Kopadze published an explainer on graph engineering. It landed with me immediately, and it took me a while to work out why, because on the face of it it was describing something I already did.
What it gave me was a test I could state in one line: an edge between two steps only exists if real data passes along it.
That is not a heuristic. It is a rule, and rules can be checked by a machine.
But there was a gap between what that writing described and what I wanted. Nearly all of it was retrospective. Draw the graph of what happened, look at where it went wrong, learn something. Useful. It is also an autopsy.
I wanted it in the second planning pass, before anything runs. Same test, different moment. Not what shape did that turn out to be, but what shape is this, now, while it is still free to change.
So I built the checker. It is called ccgrapher, it is open source under Apache 2.0, and the design came out of a handoff document I wrote while reading that article. The fake edge test, the diamond pattern and the failure modes are Kopadze’s. What I added was the part that runs before you commit to anything.
The thing it found that I had not asked about
I pointed it at my own last release, which is how I got the nine-to-three number above. Then it flagged something else.
The node representing the CI check said it expected nine results. Only eight edges reached it.
That was true. CI had been red on main for five days. Every merge in that release had gone out without a working check, including one P1 that shipped blank pages to production.
I had not told the linter what CI was. It has no concept of continuous integration, no idea what a test suite is or why it matters. It knew that nine things were supposed to arrive somewhere and that eight did.
That is the argument for structure in one incident. Get the shape right and the shape tells you things nobody thought to look for.
Why this closes a loop
Earlier in this series I sent more than fifty agents at a website and got back something unrecognisable. That was scale without structure: no shared definition of right, so fifty reasonable decisions added up to a wrong one.
This is the opposite failure and it produces the same silence. Structure that looks completely fine and is fake. Nine steps in a tidy row, every one of them defensible, six of them waiting on nothing at all.
Both are the graph being wrong. One has no shape. The other has a shape that is decorative.
What to actually do with this
You do not need the tool. The tool is what happens when you get annoyed enough to automate a question, and the question is the valuable part.
Take the plan you have right now, the one you are reasonably happy with. Go down it line by line and ask, for each item, what specifically is this waiting for. Not what comes before it in the document. What data does it need that does not exist until something else finishes.
If the answer is nothing, it does not belong in a queue.
Most plans I have written, including plans I was proud of, are a list wearing a graph’s clothes. Yours probably is too, and the only way to find out is to count.
Next, and last: what happens after it is live.