Boil the Ocean

Transfers

You cannot boil the ocean. The physical impossibility is so self-evident that the expression needs no explanation, and that is precisely its power: it maps the absurdity of an impossible physical task onto the absurdity of attempting to solve every problem at once in a software project. When someone says “we’re trying to boil the ocean,” they mean the scope is not merely ambitious but categorically unachievable.

Key structural parallels:

• Scale beyond capacity — the ocean is not just large; it is a quantity so far beyond any human heating apparatus that the gap between means and ends is comic. This maps onto projects whose scope dwarfs the available team, time, and budget by orders of magnitude. The metaphor doesn’t say “this is hard.” It says “this is impossible, and you should feel embarrassed for trying.”
• Undifferentiated effort — to boil the ocean, you would need to heat all of it, everywhere, at once. You can’t boil the Pacific and leave the Atlantic for Q2. This maps onto the scoping failure where a team refuses to prioritize: every feature is critical, every edge case must be handled, every integration must be built before launch. The ocean metaphor names the refusal to decompose.
• Energy dissipation — even if you could generate enough heat, the ocean would radiate it away faster than you could add it. Effort disperses into an unbounded problem space. In software, this is the team that builds a little of everything and finishes nothing: energy spent on thirty half-built features is energy lost.
• A natural limit, not a human failure — the ocean’s volume is not anyone’s fault. The metaphor shifts blame from the team’s competence to the project’s definition. “We can’t boil the ocean” is gentler than “we over-promised,” which makes it useful politically: it criticizes the plan, not the people.

Limits

• Some oceans should be boiled — the metaphor assumes that vast scope is always a mistake. But some problems genuinely require comprehensive solutions. A platform migration, a security overhaul, a compliance rewrite — these resist decomposition because the value only materializes when the whole thing is done. Calling them “boil the ocean” projects can discourage necessary ambition.
• The metaphor is binary — you either boil the ocean or you don’t. There is no “boil a lake” or “boil a pond” in common usage. This creates a false dichotomy between impossibly large and sensibly scoped, when most real projects exist on a spectrum. The expression doesn’t help you figure out how much scope is too much; it only diagnoses the extreme case.
• It conflates scope with strategy — a project with enormous scope and a phased delivery plan is fundamentally different from one with enormous scope and no plan at all. The metaphor doesn’t distinguish between “we’re doing too much” and “we’re doing too much at once.” An organization that successfully builds AWS has boiled the ocean, one teaspoon at a time.
• The physics don’t actually map — boiling the ocean is impossible because of thermodynamics. Building a large software system is not impossible; it is merely expensive and slow. The metaphor imports a sense of physical impossibility that overstates the real constraint, which is resource allocation. This rhetorical escalation can shut down conversations that deserve more nuance.

Expressions

• “We’re trying to boil the ocean” — the diagnostic, deployed in sprint planning or roadmap reviews to signal that scope is out of control
• “Let’s not boil the ocean” — the preemptive constraint, used when scoping new work to prevent feature creep before it starts
• “You don’t need to boil the ocean” — the reassurance to an over-ambitious engineer or product manager, granting permission to do less
• “Stop trying to boil the ocean and pick one thing” — the directive form, demanding prioritization
• “That’s an ocean-boiling project” — adjective form marking a proposal as infeasibly scoped

Origin Story

The expression predates software engineering and appears in American business vernacular from at least the 1980s, where it was used in management consulting to describe strategy engagements with no clear boundaries. Its exact origin is unclear, but the logic is old: the impossibility of heating a body of water vastly larger than one’s means is a near-universal folk insight.

In software, the expression gained currency during the enterprise software era of the late 1990s and 2000s, when large-scale ERP and platform projects routinely failed due to uncontrolled scope. The term became a standard warning in agile and lean methodology communities, where it serves as shorthand for the opposite of iterative delivery.

References

• McConnell, S. Software Estimation: Demystifying the Black Art (2006) — discusses scope overreach as a primary cause of estimation failure
• Ries, E. The Lean Startup (2011) — the iterative alternative to ocean-boiling, framed as minimum viable product