Winston Royce gets the blame for inventing “waterfall” in software delivery, even though the name was assigned six years after Royce’s paper Managing the Development of Large Software Systems. It gets worse for Royce, because the same paper, written in 1970, also suggested using something far better than “waterfall”.
Waterfalls have a natural beauty, and that’s why people love visiting them. What you don’t realize is their power. In the UK, many of our waterfalls have names that include the word “Force”, including our largest waterfall by volume, High Force in County Durham.
At peak, 100 cubic meters drop over the edge of the 21.5-meter fall every second. A typical day still delivers a fifth of that. Either way, that’s a lot of water. Yet it’s not enough to make the global flow rate rankings, as only waterfalls with over 150 cubic meters per second make the cut.
It might help to imagine between 12 and 62 bathtubs per second crashing down at High Force. You’d need 1,300 standard builder’s skips per minute to handle the water at peak.
Work is like water
I wrote an article for The New Stack in 2025 titled Work Is Water, in which I compared artificial dams, weirs, culverts, and sluices to how we approach work. Our desire to control nature leads us to build great concrete runways for water as we try to shift it quickly to a destination. This fails.
We’ve now realized that the best way to control nature is with more nature. The winding path of a river, beaver dams, and the landscape slow the water and prevent downstream flooding better than our attempts to rush it downstream and away.
Everyone has experienced this in the workplace. When you try to rush the work, all you do is create floods. Floods of testing. Floods of bugs. Floods of rework. We’re not listening to nature when we rush the work. But I promised to explain the difference between a waterfall and a millrace.
The waterfall and the millrace
Waterfalls deliver a volume of water at their head, and gravity brings it crashing down. That’s beautiful in the British Countryside, but terrible in the workplace. When you create a large batch of work and push it into the air above a long drop, it becomes impossible to control.
Overly specified software projects are the canonical example of this. They define too much of the system up front, tipping it over the edge and flooding all downstream stages. If you believe our industry has solved this problem, I want to make you reconsider, because research shows it is not solved by turning a 12-month project into a 2-week sprint. A 2-week sprint is better than a longer project, but it still causes flooding.
That’s why you need to move away from waterfalls, no matter the flow rate, and switch to the millrace.
The crucial difference between a waterfall and a millrace is that you can control the water entering the channel. You can shut off all water to make repairs, and you can deliver the precise amount of power to the wheel when you need it. The pace is set by your need for power, and water only enters when you need it.
There is no need to let work enter the system if you haven’t completed what’s in flight. If you haven’t got feedback on the work and made improvements, you’re not done. Software teams have struggled with this definition for decades, and you can see the resistance to this definition when you find teams who call things “done”, or “done done” depending on “how done they are”. Perhaps “done” means they’ve stopped working on it, and “done done” means it’s deployed.
Software teams are abandoning work unfinished in the majority of cases. They took the most important feature, ceased work on it, deployed it some time later, and never went to find out if it works. They are now working on a less important feature, while people grow frustrated with the sharp edges left on every prior development.
Yes, the millrace is about working in small batches. That’s the big takeaway. Batches even smaller than you think, even now at the end of this sentence. The most successful team I was on worked on a single feature. Literally one. And they worked on it until people confirmed it solved their problem and had no sharp edges.
Winston Royce told people this. He said you had to involve the customer and make small, incremental changes. How did people miss this for 25 years, assuming you take the lightweight methods revolution as the moment of realization (I’d argue the majority of organizations are still working this out).
The conflict, resolved
Astute readers have noticed a metaphorical conflict. When I describe work as water, I’m leaning into the idea that nature has better water management than people do. We should remove all those human inventions that control water, I declared along the way. Then I told you to install a millrace to control the flow of work to your team. You think I’m riffing, and I haven’t thought this through.
You may, then, enjoy the denouement, though it only re-explains what I’ve already said. The millrace is the tool that will return you to nature.
Today, you have water cascading over the precipice, attempting to force work through the system and out the other end. The flooding triggers emergency mode, so you don’t take care along the way, you don’t listen for feedback signals, you can only race to “done done” abandonment, so you can rush onto the next thing.
The millrace draws water before the waterfall. It provides a smooth and calm route for the water to flow into the system. It lets you close off the stream when you need a pause to fix something or improve how you work. It’s a healthy way to exit the world of constant flooding.
But single-piece flow is the natural water course. The work trickles gently, yet the value of what you build increases because, instead of counting features, lines of code, or tokens scorched, you’re collaborating with the people using what you build to make something truly exceptional.
Leave a Reply