Module 6: Designing for Change

Sacrificial architecture

Next →

Overview

The two previous lessons gave two ways of dealing with an uncertain future: seeing it as a flow that's going to arrive (lesson 2) and keeping doors open for it (lesson 3). This lesson gives a third, and it's the most counterintuitive of all: sometimes the best way to handle uncertainty isn't to prepare the system for change, but to knowingly build something you're going to throw away. A sacrificial architecture is a piece built knowing from the start that it will be replaced —a prototype, a first system, a scaffold— whose job isn't to last, but to teach: validate an idea, discover the real requirements, reduce the uncertainty so the version that will last gets built well. And then it's discarded, without guilt, because it did its job.

This sounds like heresy in a culture that rewards "building it right in one go" and treats throwing away code as a failure. But it's a direct consequence of the module's thesis. If the architecture is a flow and the day-one design erodes (lesson 2), and if the greatest risk is building something expensive on wrong assumptions, then spending a little to learn before spending a lot is one of the most profitable investments an architect makes. The disposable prototype is cheap; what it buys —the certainty about what to really build— is worth much more than its cost. This lesson measures it: it compares building "for production" from day one under uncertainty (risking rebuilding everything if the assumptions fail) against building first a sacrificial prototype that reduces that uncertainty —and shows when the scaffold pays for itself—.

Connection with the module. It's the third piece of the basic stance (flow, optionality, sacrificial). It connects directly with lesson 3: sacrificial architecture is a way of buying information instead of buying an option —when the uncertainty isn't "will this change come?" but "what is it we really need to build?", a disposable prototype resolves that doubt cheaply—. And it connects with the two abysses to come: building the "production" system under high uncertainty is a form of over-engineering (you build expensively something you didn't know would work). Frontier with the sister guide: here we don't measure technical debt or classify the decision formally; we work the stance of the architect who allows themselves to build to throw away, and knows when that's wisdom and not waste.

An analogy: the scaffold that raises the building and then is removed

Look at any building under construction and you'll see something curious: much of what's on the site isn't going to be part of the building. The scaffold around the facade, the wooden formwork that holds the concrete while it sets, the crane, the temporary ramps, the workers' cabin. All that is built with effort and money, used for months, and then removed and discarded. No one looks at a finished building and says "what a waste, they spent on a scaffold that's no longer there". On the contrary: the scaffold is what made it possible to build the building well. Without it, there'd be no way to raise the walls or pour the roofs in place.

Think of the formwork in particular, because it's the most exact analogy. When a concrete slab is poured, the concrete is liquid: it doesn't hold itself. So first a wooden structure is assembled —the formwork— in the exact shape of the slab, the concrete is poured on top, and it's left to set. When the concrete is solid and holds itself, the formwork is removed. The formwork was never part of the building; it was the temporary mold that gave the building its shape while it hardened. Building it was real work, with real wood and real hours, and discarding it is the right thing —keeping the formwork stuck to the slab "so as not to waste it" would be absurd, it would ruin the building—.

Now think of two site foremen facing a slab of a new and complicated shape they've never done. The first despises the formwork: "the formwork is waste, let's pour the concrete directly with definitive supports". Since they didn't test the shape first, the slab comes out crooked, the concrete spills, and everything has to be chipped out and redone —this time with formwork—. They paid for the mistake of skipping the scaffold. The second first assembles a cheap formwork, tests that the shape works, adjusts, and only then pours the definitive concrete, which comes out perfect on the first try. They spent on a formwork they threw away —but that formwork saved them from redoing the whole slab—.

Here's the point: knowingly building something you're going to throw away isn't waste; it's the scaffold that makes it possible to build well what will last. The software sacrificial prototype is the formwork: it's built cheaply, used to discover the right shape —the real requirements, the one that works—, and discarded when the "production" system holds itself. The architect who despises the prototype "because it's waste" is the first foreman: they pour the concrete over a shape they didn't test, and pay the rework of redoing the slab. This lesson measures when the formwork pays for itself.

Worked example: the disposable prototype vs. building "in one go"

We're going to put a number on when the formwork is worth it. Mercado wants to build a new capability —say, a recommendations system— and there's uncertainty about the requirements: it's not clear what data matters, what shape it should have, whether the approach will work. We compare two ways of building it:

  • build_to_keep — build the "production" architecture from day one. Costs P (the production build, expensive). But under high uncertainty there's a probability q of having built the wrong thing —discovered only after building it, when it's already in use or nearly—, and then it has to be rebuilt: pay P again. It's pouring the concrete without formwork.
  • sacrificial — build first a cheap, disposable prototype (costs S, much less than P) whose only job is to learn the real requirements. It's thrown away, and with what's learned the production version is built right on the first try (costs P, no rebuild). It's assembling the formwork, testing the shape, and pouring the concrete once.

The comparison depends on q, the requirements uncertainty. build_to_keep costs P + q × P (produces and, with probability q, rebuilds). sacrificial costs S + P (throws away the prototype but builds production once):

# Sacrificial architecture: KNOWINGLY building something you'll throw away. A
# cheap prototype that VALIDATES and then is replaced. We compare two ways of
# building a new Mercado capability under requirements uncertainty:
#   build_to_keep : invest in a "production" architecture from day 1.
#                   Costs P. But under high uncertainty there's a probability q of
#                   having built the wrong thing -> it's rebuilt -> P is paid again.
#   sacrificial   : build first a CHEAP, disposable prototype (costs S)
#                   to learn the real requirements; it's thrown away, and with what's learned
#                   the production version is built RIGHT on the first try (costs P, no rebuild).
PROD_COST  = 100000  # P: build the production version
PROTO_COST = 15000   # S: the disposable prototype, cheap


def expected_build_to_keep(q):
    # pays production and, with probability q, rebuilds it entirely
    return PROD_COST + q * PROD_COST


def expected_sacrificial():
    # throws away the prototype (S) but builds production RIGHT once
    return PROTO_COST + PROD_COST


breakeven_q = PROTO_COST / PROD_COST

print(f"{'uncertainty q':>16}{'build_to_keep':>16}{'sacrificial':>14}   wins")
print("-" * 62)
for q in [0.10, 0.20, 0.30, 0.60, 0.80]:
    btk = expected_build_to_keep(q)
    sac = expected_sacrificial()
    winner = "sacrificial" if sac < btk else "build_to_keep"
    print(f"{q:>16.2f}{btk:>16,.0f}{sac:>14,.0f}   {winner}")
print("-" * 62)
print(f"Break-even point: q = {breakeven_q:.2f} ({breakeven_q * 100:.0f}%).")
print(f"When requirements uncertainty exceeds {breakeven_q * 100:.0f}%, throwing 15,000 USD")
print("into a disposable prototype comes out cheaper than risking rebuilding")
print("the 100,000 of production. The scaffold is paid for to raise the building well.")

What to expect. Running the file, the output is exactly this:

   uncertainty q   build_to_keep   sacrificial   wins
--------------------------------------------------------------
            0.10         110,000       115,000   build_to_keep
            0.20         120,000       115,000   sacrificial
            0.30         130,000       115,000   sacrificial
            0.60         160,000       115,000   sacrificial
            0.80         180,000       115,000   sacrificial
--------------------------------------------------------------
Break-even point: q = 0.15 (15%).
When requirements uncertainty exceeds 15%, throwing 15,000 USD
into a disposable prototype comes out cheaper than risking rebuilding
the 100,000 of production. The scaffold is paid for to raise the building well.

Read the winner column top to bottom, because the crossover tells the whole story.

With q = 0.10 (low uncertainty), build_to_keep wins. When you're fairly sure of the requirements —only 10% probability of having been wrong—, building the production version directly comes out cheaper: 110000 against the sacrificial path's 115000. Here the prototype would be an unnecessary detour —assembling formwork for a slab you already know how to do with your eyes closed—. When you know what to build, build it. The sacrificial prototype isn't a ritual always performed; it's a response to uncertainty, and if there's no uncertainty, it's not needed.

From q = 0.20 (moderate uncertainty) on, sacrificial wins, and the advantage grows fast. With 20% uncertainty, the prototype already pays (115000 vs 120000). With 60%, the difference is enormous: 115000 against 160000. With 80%, 115000 against 180000. Notice the pattern: the cost of sacrificial is flat (always 115000), because the prototype eliminates the uncertainty —after learning, production is built right once, no matter how confusing the problem was at the start—. The cost of build_to_keep grows with the uncertainty, because the more confusing the problem, the more probable rebuilding the 100000 of production. The prototype buys certainty at a fixed price; building in one go leaves the bill exposed to the uncertainty.

And in the middle, the break-even point: q = 15%. It comes from S / P = 15000 / 100000. The rule it gives: when requirements uncertainty exceeds 15%, throwing 15000 into a disposable prototype comes out cheaper than risking rebuilding the 100000 of production. Below that threshold (you know well what to build), build it directly. Above it (you're not sure), build the formwork first. The number turns "do I make a prototype or go directly?" —usually decided by taste or by haste— into a comparison with a threshold.

Notice what the model captures, which is the heart of why sacrificial architecture isn't waste: the sacrificial prototype "wastes" 15000 on something thrown away, but that spend buys the elimination of the uncertainty, which in build_to_keep costs an expected value of q × 100000 in rebuild. With q = 60%, that exposed uncertainty is worth 60000 expected; paying 15000 to eliminate it is a great deal. The architect who says "let's not make a prototype, it's throwing money away" sees the 15000 that gets discarded, but doesn't see the 60000 expected they're risking paying in rework. The formwork that's removed isn't the waste; skipping the formwork and chipping out the slab is the waste.

As bars, with q = 0.60:

Total expected cost (USD), uncertainty q = 60%
 build_to_keep |################################  160,000
 sacrificial    |#######################           115,000
                 ────────────────────────────────
 The prototype throws away 15,000 but avoids 60,000 expected in rebuild.

Deep dive: what a sacrificial architecture is and isn't

The concept has edges worth sharpening, because it's easy to confuse a sacrificial architecture with things that aren't —and that confusion leads to using it wrong or rejecting it for the wrong reasons—.

What it is. A sacrificial architecture is a piece built with the explicit intention, from the start, of replacing it. The intention is what defines it. It's not "we built something, it went wrong, and we threw it away" —that's a mistake—; it's "we built something cheap to learn, knowing we'd throw it away, and we threw it away because it did its job". Martin Fowler gives the classic example: eBay, Amazon, and other giants built first systems they knew wouldn't scale, used them to validate the business and learn the domain, and replaced them when the business justified it. Those first systems weren't failures; they were scaffolds that made the real building possible. Their value wasn't in lasting, but in teaching and in getting the product to market while the uncertainty was maximum.

What it isn't —three dangerous confusions—. First, it's not an excuse to build badly with no intention of replacing. "We do it quick and dirty and we'll fix it later" isn't a sacrificial architecture if there's no real replacement plan; it's simply technical debt in disguise, and the "later" never comes. Sacrificial architecture requires the explicit commitment to throw away the prototype —if you're going to keep it, it wasn't sacrificial, it was production disguised as a prototype, and there's the danger—. Second, it's not a prototype that slips into production. The most common and most expensive mistake: a disposable prototype is built, it works, and out of haste or inertia it's put into production "temporarily" —and the temporary becomes permanent—. Now you have a production system made with the quality of a formwork: it's leaving the formwork stuck to the slab. The sacrificial prototype has to be discarded; if it survives, it stopped being sacrificial and became a problem. Third, it's not the same as a spike. A spike is an exploration of hours or days to answer a specific technical question; a sacrificial architecture can be a whole system that lives for months in real production while the business matures. They share the DNA —building to learn— but differ in scale.

The discipline that makes it work: committing to throw away. The risk of every sacrificial architecture isn't building it; it's not having the courage to discard it when it's time. A prototype that works generates enormous pressure to keep it —"it already works, why redo it?"—, and giving in to that pressure turns the scaffold into permanent structure, with all its deficiencies. That's why the architect who uses sacrificial architecture well establishes from the start, and communicates, that the piece is going to be replaced: they put the date or the condition of the replacement in writing (here the ADR is the vehicle —its mechanics is the sister guide architecture-decisions and its communicative use module 3—), so that "we throw it away" is a decision made in advance and not an argument lost under the pressure to keep what already works. Just as the foreman knows, before assembling the formwork, that they're going to remove it: it's not a doubt they resolve at the end, it's part of the plan.

How it relates to the optionality of lesson 3. Both handle uncertainty, but of different types, and it's worth not confusing them. Optionality handles the uncertainty about whether a change will come —you keep a door open just in case—. Sacrificial architecture handles the uncertainty about what to build —you build something cheap to discover the answer—. One buys the right to react; the other buys information. And there's a bridge between the two: the sacrificial prototype, by reducing the uncertainty about what to build, tells you where to put the real seams in the production version —that is, which options to buy—. You learn with the formwork which walls of the definitive house are worth leaving movable. That's why the three pieces —flow, optionality, sacrificial— form a coherent stance: seeing the system as a film, keeping open the doors probability justifies, and building to throw away when the best investment is learning cheaply before spending dearly.

Common mistakes

Despising the prototype "because it's throwing money away". What happens: the architect refuses to build a disposable prototype under high uncertainty —"let's not spend on something we're going to throw away, let's do it right in one go"— and builds the production version directly on requirements they didn't validate; when they turn out wrong, they rebuild. Why it happens: they see the 15000 that gets discarded (visible, present) but don't see the q × 100000 expected they're risking paying in rebuild (invisible, future). How to spot it: if there's real uncertainty about what to build and yet they jump directly to the production architecture "so as not to waste", it's the foreman who pours concrete without formwork. How to fix it: compare the prototype's cost with the expected value of the uncertainty it eliminates —if the uncertainty exceeds the break-even point (S/P), the prototype pays for itself—. The waste isn't the formwork that's removed; it's chipping out the slab for having skipped it.

Not having the courage to throw away the prototype (slipping it into production). What happens: a disposable prototype is built, it works, and out of haste or inertia it's put into production "temporarily"; the temporary becomes permanent, and now there's a production system with the quality of a scaffold. Why it happens: a prototype that works generates strong pressure to keep it —"it already works, why redo it?"— and giving in to that pressure feels efficient. How to spot it: if a prototype built "to learn and throw away" has been in production for months with no replacement plan, the formwork slipped into the building. How to fix it: commit to throwing it away from the start, in writing (with the replacement date or condition recorded in an ADR), so that "we throw it away" is a decision already made and not an argument lost under the pressure to keep what works. If you're going to keep it, it wasn't sacrificial —it was production in disguise—.

Calling building badly with no replacement plan "sacrificial". What happens: a team builds something quick and dirty and justifies it as "sacrificial architecture", but there's no intention or real plan to replace it; it's technical debt with an elegant name. Why it happens: the concept sounds sophisticated and gives permission to lower the quality, so it's used as an alibi. How to spot it: if on asking "when and under what condition is this replaced?" there's no answer, or the answer is "someday", it's not sacrificial —it's debt—. How to fix it: require that every sacrificial architecture have, from the start, the explicit commitment to replace (date or condition), because the intention to throw away is what defines it. Without that commitment, "sacrificial" is just a pretty word for "we did it badly and don't plan to fix it".

Exercises

Exercise 1 — Prototype or direct? For each Mercado situation, say whether you'd build a sacrificial prototype first or go directly to the production version, using the uncertainty break-even-point idea: (a) Mercado wants a machine-learning recommendation engine, a domain the team has never touched and where it's not clear what data or approach will work; (b) Mercado wants to add a "gift note" field to the checkout, a small and well-understood change; (c) Mercado wants to enter a new business model (subscriptions) where it's not even clear what customers will want or how it will charge.

See solution

  • (a) Sacrificial prototype. The uncertainty is high —new domain, no clarity on data or approach—: it's well above the break-even point. Building the "production" engine directly risks rebuilding it entirely when it's discovered the approach didn't work. A disposable prototype —a simple model with sample data, to learn what works— costs little and eliminates that uncertainty before investing in the production version. It's the formwork for a slab of a new shape.

  • (b) Directly to production. The uncertainty is very low —a text field in the checkout, a small and well-understood change—: it's below the break-even point. Making a disposable "gift note" prototype would be an absurd detour, assembling formwork to hang a picture. When you know what to build, build it. Sacrificial architecture responds to uncertainty; without uncertainty, it's pure overhead.

  • (c) Sacrificial prototype, and an important one. The uncertainty is maximum —it's not clear what customers want or how it charges—: well above break-even, and besides the cost of building a wrong subscriptions model "for production" is enormous. Here a sacrificial prototype (maybe even a whole, simple system, in real production with real customers, to learn what works) is the most profitable investment: it validates the business and discovers the real requirements cheaply, before building the definitive system. It's the eBay/Amazon case: the first system you knew you'd replace, that got you to market and taught you the domain.

The pattern: sacrificial architecture is justified by uncertainty. High (a, c) → prototype; low (b) → direct. It's not a ritual always performed, it's a calibrated response to how much you don't know.

Exercise 2 — The prototype that stayed. Mercado's team built a disposable prototype of the subscriptions system "to learn and throw away". It worked, and eight months later it's still in production, with no replacement plan, accumulating patches. Explain what went wrong —which of the three mistakes the team made—, why it's dangerous, and what they should have done to avoid it.

See solution

The mistake was not having the courage to throw away the prototype: they slipped it into production. A formwork was built —a prototype with the quality of something disposable, made to learn fast, not to last— and instead of removing it, it was left stuck to the slab. The typical pressure explains it: "it already works, why redo it?". But giving in to that pressure turned a sacrificial architecture (legitimate) into a production system made with scaffold quality (a problem).

Why it's dangerous: a disposable prototype is built with deliberate shortcuts —without the robustness, security, scalability, or seams a production system needs—, because its job was to teach, not to last. Leaving it in production means Mercado's subscriptions system —which charges real money to real customers— runs on those shortcuts. And since it wasn't designed to last, every change fights against it and patches accumulate (the lesson 2 drift). Worse: each month that passes, replacing it is more expensive and riskier, because more things depend on it. The formwork stuck to the slab keeps weakening the building.

What they should have done: commit to replacing it from the start, in writing, with a replacement condition or date recorded (an ADR: "this prototype is replaced when we exceed X subscribers / before quarter Y"). That prior commitment is what shields the decision to throw away against the later pressure to keep: when the moment comes, "we replace it" is already a decision made, not an argument lost against "but it already works". The discipline of sacrificial architecture isn't in building the prototype —that's easy—; it's in having, in advance, the commitment to discard it. Without that commitment, it wasn't sacrificial: it was technical debt that called itself a prototype.

Exercise 3 — The 15000 you see and the 60000 you don't. A Mercado manager objects to building a sacrificial prototype for the recommendation engine (estimated uncertainty q = 60%): "are you asking me for 15000 dollars to build something we're going to throw away? That's throwing away the money. Build it right the first time". Using the example's numbers, respond to their objection by explaining what cost they're seeing and which they aren't.

See solution

The manager is seeing a real cost —the 15000 of the prototype that gets discarded— but is ignoring a much bigger cost their objection hides: the expected value of the rebuild risked by building "in one go" under high uncertainty. With q = 60%, building the production version directly (build_to_keep) has a 60% probability of being wrong and needing to be rebuilt entirely, which adds an expected value of 0.60 × 100000 = 60000 in rework on top of the 100000 of the initial build —160000 expected in total—.

The sacrificial prototype costs 115000 in total (15000 of the prototype + 100000 of the production built right once, because the prototype eliminated the uncertainty). That is: the 15000 the manager sees as "throwing away money" buys the elimination of an uncertainty that, without them, is worth 60000 expected in rebuild. It's a great deal: you spend 15000 to avoid risking 60000. The concrete answer to the manager: "I'm not asking you to throw away 15000; I'm asking you to spend 15000 so as not to risk 60000. Building 'in one go' under this uncertainty isn't cheaper, it's 45000 more expensive in expected value (160000 vs 115000). The prototype isn't the waste; the waste would be building the production engine on assumptions we didn't validate and having to redo it".

It's exactly the foreman who sees the formwork that's removed ("what a waste of wood") but doesn't see the slab that would have to be chipped out and redone if they pour the concrete without it. The visible cost of the scaffold hides the bigger —and invisible— cost of skipping it.

Summary and next step

In this lesson you installed the third piece of the stance, the most counterintuitive: sacrificial architecture, knowingly building something you're going to throw away because its job is to teach, not to last. You saw, with the scaffold and the formwork, that building to discard isn't waste but the temporary mold that makes it possible to build the definitive thing well —and that the real waste is skipping the formwork and chipping out the slab—. And you measured it: under requirements uncertainty, a disposable prototype of 15000 eliminates an uncertainty that, building "in one go", would cost up to 60000 expected in rebuild; the break-even point is at 15% —above it, the formwork pays for itself—. You sharpened the concept's edges: the explicit intention to replace is what defines it, the greatest risk is not having the courage to throw away the prototype (slipping it into production), and "sacrificial" with no replacement plan is just technical debt with an elegant name.

Before moving on you should be able to: explain why a disposable prototype isn't waste but a purchase of information; distinguish a legitimate sacrificial architecture from a prototype slipped into production and from disguised technical debt; and compute by eye whether a change's uncertainty justifies building the formwork first.

With this lesson you closed the three pieces of the basic stance —flow, optionality, sacrificial—. Lesson 5 opens the second half of the module, that of the two abysses the architect walks between. It starts with the first: over-engineering, and the YAGNI line. You'll see the mistake of building flexibility "just in case" for imagined futures that almost never come —the planner who paves twelve lanes for a town—, and execute how much it costs to carry all that unused flexibility against paying the rework only of the changes that really arrive. With numbers, so that "don't build it until you need it" stops being a slogan and becomes a measurement.

Resources

  • Martin Fowler, "Sacrificial Architecture" (2014) — martinfowler.com/bliki/SacrificialArchitecture.html. The text that names the lesson and its thesis: good architects build systems knowing they'll be replaced, and that isn't failure but strategy. The eBay and Amazon examples come from here. Short and essential. In English.
  • Frederick Brooks, The Mythical Man-Month (Addison-Wesley, 1975), ch. 11 "Plan to Throw One Away" — the historical origin of the idea: in a project with uncertainty, you're going to build a system you'll throw away anyway, so plan for it. Brooks later qualified it (not always a whole "one"), but the principle of building to learn remains valid. In English.
  • Neal Ford, Rebecca Parsons, and Patrick Kua, Building Evolutionary Architectures (O'Reilly, 2017) — on why designing for replacement and evolution is more realistic than designing for permanence. The module's general framework. In English.
  • Andrew Hunt and David Thomas, The Pragmatic Programmer, 20th Anniversary Edition (Addison-Wesley, 2019), topics "Prototypes and Post-it Notes" and "Good-Enough Software" — on prototyping to learn and discarding without guilt, and why disposable software has a different purpose from production's. In English.
← PreviousKeeping the doors openNext →The YAGNI line