Snowy 2.0 is now expected to cost up to $25 billion, and it won’t be finished until late 2029. When it was announced in 2017, the figure was $2 billion, with, as Dominic Ahiaga-Dagbui of Deakin University’s Megaprojects Research Group puts it, “no business case to back that up at the time”.[1] That is more than twelve times the first number, and eight years later than first projected.
My first reaction, reading the coverage, was irritation of a very particular kind. I have spent most of my working life explaining why software estimates are unreliable. In my book, Code is Design, I argue that this is not because software people are bad at estimating. It is because of what software is. And to make that argument I leaned, as everyone does, on the contrast with building a bridge. We know how to build a bridge. Once the design is done, a good estimator can price it with a known margin of error.
So when the people who build tunnels and dams miss by a factor of twelve, it is fair to ask whether I had the contrast wrong. Having read the reports, I don’t think I did. I think Snowy 2.0 broke the one rule that construction can follow and software cannot.
The rule
Here is the distinction as I put it in the book:
When a construction firm estimates the cost of building a bridge, they are working from a design that is, for all practical purposes, complete. The structural calculations have been done. The materials have been specified. The sequence of construction operations has been worked out. The unknowns are real – ground conditions may differ from the survey, material prices may move, weather may cause delays – but they are unknowns about the conditions under which a known scope of work will be executed.[2]
Uncertainty about conditions is hard, but it can be priced. Uncertainty about scope cannot. A construction estimate is trustworthy for one reason only: the design came first.
Software never gets to that point before the work starts, because in software the code is the design. Writing code is not building to a plan. It is making the plan, at its finest level of detail, one decision at a time. The actual “construction”, turning that code into a running program, is a compile or a build. It takes seconds, or at most a few hours, and costs almost nothing. Developers do it dozens of times a day just to try out an idea. As I wrote: “Can you imagine an engineer proposing that we just build a bridge to see if it will do the job well, knowing that we can just tear it down and try a different approach if not?”[2]
So the rule is simple. Commit to a number after the design is done. Construction can follow it. Software can’t, because by the time the design is done, so is the software.
What Snowy did
Now read the Snowy record with that rule in mind.
In 2017, a feasibility study put the cost at between $5.4 billion and $6.9 billion. That was a range, which is the honest form of an early estimate. A year later a final investment decision was made on a single figure, $6.1 billion, “before geological studies had been finished”, according to the Guardian.[^3] By three years ago the estimate had doubled to $12 billion, and the latest official report says even that “was based on incomplete construction designs”.[1]
Then there is Florence, one of the project’s tunnel-boring machines. She hit “unforeseen soft ground just 150 metres into a 15 kilometre excavation”, and “didn’t move for nearly a year”.[3]
Ground conditions are exactly the kind of risk my bridge estimator can price, if the geology has been done. Here it had not. The digging became the survey. The construction phase was being used to discover the design, which is precisely what construction is not supposed to do, and precisely what software development always does.
In other words, Snowy 2.0 was not a failure of construction estimating. It was a construction project run like a software project, with a software project’s uncertainty and a construction project’s price tag. When software discovers its design during the build, you lose some weeks and recompile. When a dam does it, you have a 143-metre machine sitting still under a mountain for a year.[3]
It is not a one-off. Deloitte found earlier this year that 13 publicly funded road, rail and energy projects had blown out by $130 billion beyond their first estimates.[1] Closer to home, Melbourne’s 90-kilometre Suburban Rail Loop was announced at $50 billion in 2018, “years before” there was an economic business case for it. Its first stage, the 26-kilometre SRL East, is expected to cost at least $33 billion on its own, and the Victorian Auditor-General warned in August that it “is unlikely to be delivered on budget and on time”.[1] Ahiaga-Dagbui is blunt that Australia has “a terrible record under both parties”. This is not about who announced what, or whether Snowy 2.0 or the Loop is worth building. That is a different argument. It is about announcing first and designing later.
How a guess becomes a promise
Software people know this pattern well, because we live inside it. In the book I call it the estimate trap. An early number, given at the point when least is known, gets written into a budget. The budget implies a timeline. Contracts are signed and announcements are made around it. “The number that was always a guess is now load-bearing: other things rest on it, and revising it requires revising them.”[2]
A public infrastructure announcement is the purest form of that trap. The number is said out loud, by a senior politician, often years before the design is done. From then on, every revision is reported as a blowout rather than as what it really is: the estimate finally catching up with the design.
In an earlier post[4] I wrote about losing a pitch because I insisted on giving an honest estimate. We said eight to twelve months; the client wanted six, and the firm that promised six got the job. It ran for over two years, cost about three times what we had proposed, and was scrapped. I take no pleasure in that. At any point in the design lifecycle, there is a limit to how certain anyone can honestly be.
What software has learnt, slowly
Software has had to find its way out of this trap, because it has no choice. The useful idea is old: the cone of uncertainty. At the very start of a project, an honest estimate “might reasonably vary by a factor of four in either direction”, and it narrows as the design proceeds.[2] The practical answer that follows from it is to stop asking a single early number to carry a final commitment:
An order of magnitude estimate can be used to approve a discovery phase without being used to approve the full project. The discovery phase produces a narrower estimate, which is used to approve the next phase. The commitment grows as the cone narrows.[2]
Public works could do this more easily than software can, because public works can actually reach the narrow end of the cone before construction begins. Finish the geology. Finish the construction design. Then commit. Ahiaga-Dagbui’s recommendation is essentially that: commit only “after they’ve actually done the work on the design, risks, costs and delivery challenges”, with a truly independent authority to check the estimates.[1]
That is the irony that annoyed me. Software can’t follow the rule, and has had to invent staged commitments and honest ranges to cope. Construction can follow it, and too often chooses not to, because a single round number makes a better announcement than a range and a study.
With a state election a few weeks away, there will be plenty of big numbers said out loud. The question worth asking of each one is not whether it is too high or too low. It is simpler: has the design been done yet? If not, the number is a guess with a decimal point, and we should treat it as one.
Also on the blog since last week’s post…
Natural Is Not an Argument “Intuitive” is the software trade’s word for “natural”. It sounds like a description but works as a verdict. A content management system that was sold to us as needing no training, and what Bruno Latour can teach us about labels like that.
Odysseus Wept Homer’s greatest hero pulls his cloak over his head and weeps, and the poem thinks no less of him. The stiff upper lip was added later, in translation, and I wonder what that cost the Greek men of my father’s generation who came here and learnt not to speak of loss.
Free to Use, Not Free to Keep The recent PHP flaws had Australian government websites going offline as a precaution. The software is free to use, but someone has to pay to keep it safe, and in forty years I never saw that line in a budget.
Just a Little, I Want to Be Like That A 22-year-old told researchers the masculinity content on his feed was toxic, but “just a little I want to be like that”. Young men are pulled in contradictory directions, and the manosphere sells them one cheap rule.
Would You Mind Leaving the Room? Sixty years ago, people confided in ELIZA, a program that simply handed their words back as questions. I wrote my own version in BASIC on a MicroBee, and the version of that delusion I met most at work was users trusting a single number because the computer produced it.
References
[1]: Dominic D. Ahiaga-Dagbui, “Why Snowy Hydro’s $25 billion cost blowout is a warning sign for other megaprojects”, The Conversation, 23 October 2026. https://theconversation.com/why-snowy-hydros-25-billion-cost-blowout-is-a-warning-sign-for-other-megaprojects-295057
[2]: Jim Karabatsos, Code is Design (2026), chapters 1 and 5.
[3]: Adam Morton and Petra Stock, “Snowy Hydro 2.0 is costing $25bn – 12 times more than its initial estimate. How did we get here?”, The Guardian, 24 October 2026. https://www.theguardian.com/australia-news/2026/oct/24/energy-snowy-hydro-2-power-project-costing-explainer
[4]: Jim Karabatsos, “The Day I Lost a Pitch by Telling the Truth“, Ground Truth, May 2026.