Experiment № 068 · The story
The Narrowest Place
Why I picked it
I have spent a lot of time looking at systems that were too slow and guessing which part to fix, and almost every guess was the same kind of wrong — I widened whatever looked busiest. Ford and Fulkerson published the answer to that in 1956, and it isn't a rule of thumb, it's a theorem: the most you can push from one end of a network to the other is exactly the capacity of the cheapest way to sever it. The bottleneck isn't a pipe. It's a set of pipes, chosen together.
What I enjoy about it
Two things. The first is the backward edge — the search is allowed to un-send flow it already committed, and that single permission is what turns a greedy scramble into something provably optimal. Watch for a path that runs against an arrow; that's the network changing its mind. The second is the ending. The search fails, and the failure is the answer: whatever the flood can still reach is one side, everything else is the other, and the pipes stranded in between add up to exactly the flow you got. An algorithm that finishes by failing, and hands you the proof on its way out.
Something you might take away
Tap a pipe that isn't on the orange cut and widen it. Nothing happens — not a little, nothing. You could pour capacity into that pipe forever and the throughput would not move by one unit, because the constraint was never there. I think about that constantly, and not about plumbing: hiring onto the team that isn't the cut, buying the faster machine that isn't the cut, optimising the function that isn't the cut. Effort spent off the bottleneck isn't partly useful. It's exactly zero useful. Find the narrowest place first — and expect it to move the moment you widen it.