← The Method
The Method · 02

Conjecture

Stage two of The Method. Propose what might be true.

The blank editor is a kind of pressure. The cursor blinks, the ticket is assigned, and every instinct trained by a decade of velocity charts says: start typing. Producing code feels like progress. Thinking feels like stalling. So we often reach for the keyboard while the problem is still least understood, and we risk encoding that misunderstanding into a structure that can resist correction for years.

Conjecture is the stage that interrupts this reflex. Having observed — having gathered what is — you now propose what might be true: a hypothesis about the shape of the solution, held openly, before it is committed to code. This is usually the cheapest stage at which to be wrong, and being wrong here, on purpose and often, is not a failure of the method. It is the method working.

Most of our problems are problems of misconception

Rich Hickey, in his 2010 talk “Hammock Driven Development,” locates the disease precisely: “most of the big problems we have with software are problems of misconception. We don’t have a good idea of what we’re doing before we do it.”1 Not problems of typing speed. Not problems of tooling. Problems of conception — defects that were present in the idea before the first character was written, and that downstream diligence may catch only after the design has become more expensive to change.

If that is where the big problems live, then that is where the leverage lives too. The most valuable thinking you will do on a project often happens before the structure is set, when changing your mind costs nothing but a crossed-out sketch. Hickey’s prescription is to take that thinking seriously as work — to use your waking, analytical hours deliberately feeding a problem to what he calls the background mind, the part of you that makes connections during a walk or a night’s sleep. There is real cognitive-science support for incubation effects in creative problem solving, but the honest version is probabilistic, not magical: stepping away can help, especially after serious engagement with a well-formed problem, and it can also do nothing.2 The hammock is not a joke about laziness. It is a claim that staring at a wall, holding a hard problem in mind, can be a legitimate and underused engineering activity. “Step away from the computer,” as the talk is sometimes subtitled, is advice about where some of the leverage actually is.

The willingness to be wrong is the engine

Here is the part most engineers find hardest, and it is the heart of why this stage is called Conjecture rather than Design. Hickey again, near the end of the same talk: “you are going to be wrong… That’s part of the game. When the facts change, do not dig in. Do it over again and see if your answer is still valid… do not be afraid of being wrong.”1

This is not folk wisdom; it is the structure of how durable knowledge is actually produced. Karl Popper, in Conjectures and Refutations, argued that knowledge grows not by slow accumulation of certainties but by an unending cycle of bold conjecture followed by determined attempts at refutation.3 A conjecture earns its keep by sticking its neck out — by being precise and consequential enough that the world, or a colleague, or a test, can refute it. The timid hypothesis that bends to fit any outcome teaches you nothing. The bold one that could be killed by a single counterexample is the one worth proposing, because if it survives serious attacks, you have learned something real enough to keep using.

Concretely, this is the difference between a spike that ends “the message-queue approach works, here’s the throughput I measured” and one that ends “I tried the message queue and it cannot preserve per-user ordering without a global lock, so that entire branch of the design is dead.” The second spike failed, and it is often the more valuable of the two, because it killed a bad conjecture in two days instead of two months. A team that treats the failed spike as wasted effort will quietly stop running spikes; a team that treats it as early refutation will conjecture more freely and spend time where the downside is still bounded. The whole economics of this stage rests on that reframing: a conjecture refuted early is not merely a cost. It is the return on the experiment.

Naming this stage Conjecture is therefore a deliberate borrowing. We are not drawing blueprints for a structure we are certain of. We are advancing a guess we intend to attack. The engineer who cannot bear to be wrong will struggle to conjecture; they will tend to defend, and defending a position you adopted before you understood the problem is one way projects die slowly.

Heuristics, not algorithms

If conjecture is a skill, it can be cultivated, and the canonical modern guide is eighty years old. George Pólya’s How to Solve It (1945) lays out a four-phase loop that maps cleanly onto The Method: understand the problem, devise a plan, carry out the plan, look back.4 Conjecture is Pólya’s second phase — devising the plan — and his enduring insight is that this phase runs on heuristics, not algorithms. There is no procedure that emits a correct design. There are only patterns of productive guessing: solve a simpler version first, find a related problem you already know how to solve, work backward from the goal, vary the problem until it becomes tractable.

It is worth noting that Hickey cites Pólya directly in “Hammock Driven Development” — “Polya wrote this amazing book called How to Solve It… It’s a terrific book” — because the lineage matters.1 The practice of deliberate, heuristic problem-solving before implementation is not a fashion of the agile era or a reaction against it. It is one of the classic statements in modern problem-solving literature, and it predates the computer.

Write the conjecture down

A conjecture held only in your head is too easy to believe. The discipline that forces it into the open is writing — sometimes a full design document, sometimes a short RFC, sometimes a one-page prose description of what you intend to do and why, written before the code when the decision is ambiguous, cross-cutting, or expensive to reverse.

Malte Ubl, a former principal engineer at Google, describes this as central to the engineering culture there: design docs are “relatively informal documents that the primary author or authors of a software system or application create before they embark on the coding project.”5 His framing of why is the load-bearing part: “As software engineers our job is not to produce code per se, but rather to solve problems. Unstructured text, like in the form of a design doc, may be the better tool for solving problems early in a project lifecycle.” When engineers at Google meet an unfamiliar system, Ubl notes, their first question is often simply: “Where is the design doc?”

The document is not bureaucracy. It is one of the cheapest available instruments for discovering that your conjecture is wrong. Prose has a useful cruelty: a hand-wave that sounds fine in your head reads as obviously unfinished on the page. The act of writing “and then the service reconciles the two states” forces the question how, exactly? — and that question, asked at design time, costs a sentence. Asked in production, it can cost an incident. (This is the seam where Conjecture begins to hand off to Formalise: the design doc says what might be true; the next stage will demand you state it precisely enough to be refuted.)

Writing the conjecture down also makes it attackable by other people, which is the social half of Popper’s engine. A design circulated as an RFC before implementation invites the colleague who has actually run this kind of system in production to say “this falls over the first time two requests race” — in a comment thread, where the fix may still be a paragraph, rather than in a postmortem, where the fix may be a weekend. The best design reviews are not approvals; they are organized attempts at refutation, and a conjecture that survives skeptical readers is more credible than one that survived only its author’s optimism. This is also why the stage rewards proposing specifically enough to be attacked: a vague design gives reviewers nothing to push against, while a sharp claim — “we shard by tenant ID and never join across shards” — hands them exactly the edge they need to find the flaw while it is still cheap.

The economics, stated honestly

There is an empirical case for front-loading this thinking, and it deserves to be made carefully, because the field is littered with inflated versions of it. A defensible version comes from Barry Boehm and Victor Basili’s “Software Defect Reduction Top 10 List” (2001), a short peer-reviewed synthesis in Computer. Two of their findings bear directly on Conjecture: that finding and fixing a defect after delivery can be far more expensive than catching it during requirements and design — on the order of 100× for large systems, though, they are careful to add, closer to 5× for small, non-critical ones — and that projects in their surveyed evidence spent roughly 40–50% of their effort on avoidable rework.6

Cite that, and cite it with the hedge. The popular “1:10:100:1000” cost-of-change curve, often attributed to Boehm’s 1981 Software Engineering Economics, has been challenged: Laurent Bossavit’s The Leprechauns of Software Engineering traces how the steepest figures get repeated without traceable measurement underneath them.7 So the honest claim is not “a design bug costs a thousand times more.” The honest claim is narrower and still powerful: a meaningful fraction of total effort is spent redoing work that a better early conjecture might have made unnecessary, smaller, or cheaper to discover, and one of the cheapest places to change your mind is on the page, before the structure exists. Conjecture is where you try to buy down rework, and the receipt is real only when later refutation shows which mistakes you avoided.

Conjecture toward the simple, not merely the easy

Not all conjectures are equal, and the axis that matters most is one Hickey drew in a second talk, “Simple Made Easy” (2011). He recovers the root of simple — sim-plex, one fold or one braid — and opposes it not to hard but to complex, many braids twisted together. Easy, by contrast, means near-at-hand, familiar, available. The two are independent, and conflating them is how systems rot. “There’s this really cool word called complect,” Hickey says. “It means to interleave or entwine or braid… This is where complexity comes from: complecting.”8

One important dimension of a conjecture’s quality is how few things it braids together. The design that keeps concerns separate — that can be reasoned about one strand at a time — is simple, even if it took hard thinking to find. The design that reaches for the familiar framework and entangles persistence with policy with presentation is easy, and you may pay for that entanglement on many future changes, because complexity, in Hickey’s precise sense, is the amount of interleaving you must understand to alter one thing safely. Conjecture toward simple. It is often harder up front and cheaper across repeated change, which is the bargain of this method in miniature.

Conceptual integrity, and the death of “plan to throw one away”

Fred Brooks gave us, in The Mythical Man-Month, the principle that should govern what you are reaching for at this stage: “conceptual integrity is the most important consideration in system design.”9 A system that reflects one coherent set of ideas — even a few good ideas applied consistently — is more likely to be learnable and usable than a richer system that is a committee’s worth of unreconciled cleverness. Conjecture is where conceptual integrity is won or lost, because it is where the central ideas are chosen. Choose few; apply them everywhere.

Brooks also gave us this stage’s most famous and most misleading maxim — and the way he later corrected it is itself a lesson in conjecture. In 1975 he wrote: “Plan to throw one away; you will, anyhow.”10 Twenty years on, in the 1995 anniversary edition, he recanted under a blunt heading — “Plan to Throw One Away: The Waterfall Model Is Wrong!” — explaining that the original advice had smuggled in the discredited assumption of a single big-bang build followed by a single big-bang rewrite.11 The mature reading is not “build a whole system to discard it.” It is: conjecture iteratively. Throw away sketches, spikes, and prototypes — small, cheap, deliberately disposable probes into the unknown — not shipped systems. Brooks did exactly what this stage asks. He proposed boldly, the facts changed, and he did not dig in. He did it over again.

The honest limit: conjecture can curdle

The failure mode of this stage is as real as its payoff, and pretending otherwise would betray the method. Taken to excess, Conjecture becomes Big Design Up Front — the architecture that grows for months and ships never, the design document that becomes a monument to a system no one is building, the “architecture astronaut” who solves problems no user has. Martin Fowler’s “Is Design Dead?” is useful here because it rejects both caricatures: evolutionary design can collapse into ad hoc tactical decisions, while planned design can overreach before code and feedback exist.12 Joel Spolsky’s “architecture astronaut” label names the adjacent pathology: abstraction that keeps climbing until it has lost contact with concrete users and products.13 The willingness to be wrong can decay into an unwillingness to commit.

Two things keep the stage honest. The first is that conjectures must be cheap and disposable. The moment a design becomes too elaborate to discard, it has stopped being a conjecture and started being a sunk cost. Spikes get thrown away. Sketches get crossed out. The deliverable of this stage is not a system; it is a proposal you would cheerfully abandon if the next stage refutes it.

The second is that a conjecture must be falsifiable, and that is precisely what the next stage exists to enforce. A proposal you cannot test is not a hypothesis; it is a daydream wearing a diagram. Popper’s whole point is that the value of a conjecture lies in its exposure to refutation. So Conjecture does not end in certainty or in code. It ends by handing a bold, simple, written proposal to Formalise, whose entire job is to sharpen it until reality can tell you whether it holds.

What Conjecture looks like in practice

The handoff

Conjecture is the stage where slow, intentional coding earns most of its keep, because it operates on the cheapest material there is: an idea not yet built. You have proposed what might be true — boldly enough to be wrong, simply enough to be worth maintaining, and in writing, so that the proposal can be attacked rather than merely believed. None of it is committed. All of it is disposable. That is the strength of the position, not its weakness.

What you hold now is a hypothesis. The next stage will not let you keep it vague. It will demand that you state it precisely enough to be wrong — and then it will try, in earnest, to refute it.

Footnotes

  1. Rich Hickey, “Hammock Driven Development,” talk at Clojure/conj, Durham, NC, October 2010. Video: youtube.com/watch?v=f84n5oFoZBc. Transcript: github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/HammockDrivenDev.md. Quotes transcribed from the talk; cite as a conference presentation. ↩ ↩2 ↩3

  2. K. J. Gilhooly, “Incubation and Intuition in Creative Problem Solving,” Frontiers in Psychology 7 (2016): 1076. DOI: 10.3389/fpsyg.2016.01076. Open access: pmc.ncbi.nlm.nih.gov/articles/PMC4956660. Useful support for incubation effects, but not a guarantee that time away will produce insight. ↩ ↩2

  3. Karl R. Popper, Conjectures and Refutations: The Growth of Scientific Knowledge (Routledge & Kegan Paul, 1963). The growth of knowledge as bold conjecture followed by attempted refutation. ↩

  4. George Pólya, How to Solve It: A New Aspect of Mathematical Method (Princeton University Press, 1945). The four phases: understand the problem, devise a plan, carry out the plan, look back. ↩

  5. Malte Ubl, “Design Docs at Google,” Industrial Empathy, July 6, 2020. industrialempathy.com/posts/design-docs-at-google. A first-hand account from a former Google principal engineer; cite as such rather than as official Google policy. ↩

  6. Barry Boehm and Victor R. Basili, “Software Defect Reduction Top 10 List,” Computer 34, no. 1 (January 2001): 135–137. DOI: 10.1109/2.962984. Note the authors’ own hedge that the ~100× post-delivery figure shrinks to ~5× for small, non-critical systems. ↩

  7. Laurent Bossavit, The Leprechauns of Software Engineering: How folklore turns into fact and what to do about it (Leanpub, 2012–2015). leanpub.com/leprechauns. Traces the citation chain behind the steep cost-of-change figures and finds much of it unsupported. ↩

  8. Rich Hickey, “Simple Made Easy,” keynote at Strange Loop, St. Louis, September 2011. Video / slides: infoq.com/presentations/Simple-Made-Easy. On simple (one braid) versus easy (near-at-hand), and “complect.” ↩

  9. Frederick P. Brooks, Jr., The Mythical Man-Month: Essays on Software Engineering (Addison-Wesley, 1975), ch. 4: “conceptual integrity is the most important consideration in system design.” ↩

  10. Brooks, The Mythical Man-Month (1975), ch. 11: “Plan to throw one away; you will, anyhow.” ↩

  11. Frederick P. Brooks, Jr., The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (Addison-Wesley, 1995), ch. 19: “Plan to Throw One Away: The Waterfall Model Is Wrong!” — Brooks’s own partial recantation. ↩

  12. Martin Fowler, “Is Design Dead?” (2004). martinfowler.com/articles/designDead.html. Especially useful for the distinction between Big Up Front Design, ad hoc evolutionary design, and design practices supported by testing, refactoring, and feedback. ↩

  13. Joel Spolsky, “Don’t Let Architecture Astronauts Scare You,” Joel on Software, April 21, 2001. joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you. Source for the “architecture astronaut” label and critique of over-abstracted design. ↩