Module 6: Designing for Change

Keeping the doors open

Next →

Overview

The previous lesson installed that the architecture is a flow that's going to receive changes. This lesson answers a question that comes straight from there: if the system is going to receive an uncertain change —one that might come, might not—, how much is it worth leaving a door open for it? The answer comes from a powerful idea engineering borrowed from finance: optionality. An option is the right, but not the obligation, to do something in the future. And an option has value even if you never exercise it, the same way fire insurance has value even if your house never catches fire: you pay a premium to have the possibility of reacting cheaply if the uncertain event occurs. In architecture, keeping a door open —a seam, an abstraction, a contract— is buying an option on a future change.

But —and this is what separates optionality from a cliché about "being flexible"— the option costs a premium, and that premium isn't always worth it. Buying the option makes sense when the change is fairly probable and fairly expensive to improvise; it becomes waste when the change is so improbable that the premium is never recovered. An architect who buys all the options for every imaginable change ends up paying premiums for insurance they'll never collect —that's the over-engineering of lesson 5—. An architect who buys none paints themselves into a corner when the probable change comes —the under-engineering of lesson 6—. This lesson gives you the tool to decide: the break-even point of an option, computed, that says when the premium pays for itself and when it's thrown away.

Connection with the module. It's the second piece of the stance (the first: the architecture is a flow; this one: keeping options open under uncertainty; the third: building to throw away). Optionality is the economic lens that makes the intuition of "leaving doors open" measurable. And it sets up the terrain of the two abysses: the break-even point you compute here is exactly the line that separates over-engineering (buying the option when its probability doesn't justify it) from under-engineering (not buying it when it does). Frontier with the sister guide: the mechanics of classifying a decision as a one-way or two-way door —when a decision is reversible— is architecture-decisions; here we work the stance of valuing the open door and knowing how much it's worth keeping it.

An analogy: the house with walls that move vs. the one that fixed everything in concrete

Return to the house, but now focus on a single detail: the interior walls.

The house that fixed everything in concrete. When building it, the owner decided every interior wall would be reinforced concrete, solid, definitive. It's cheaper in one go: no need to think about movable reinforcements or removable partitions, you pour the concrete and that's it. The house ends up perfect for the layout the owner imagined that day. The problem appears when life changes: they want to join the kitchen and the dining room into an open space, or turn two small rooms into one big one for a study. Each of those changes clashes against a concrete wall, and knocking down reinforced concrete is a major job —dust, structure, permits, a fortune—. The owner bought no option on the future layout; they saved the premium, and when the change came, they paid the full price of the remodel.

The house with non-structural walls. Another owner, when building, did something that cost a bit more: the interior walls that don't support the roof they made of light, removable partitioning instead of concrete. They paid a premium —those walls cost a bit more than pouring concrete—. In exchange, they bought an option: the possibility of reconfiguring the interior cheaply in the future. When they want the open space, a non-structural wall comes out in a day; when they want the study, two rooms join over a weekend. They demolished nothing structural, requested no major permits, spent no fortune. And here's the honest nuance: if they had never wanted to change the layout, the premium they paid for the light walls would have been money thrown away —they'd have paid for a flexibility they didn't use—. The option was worth it because the change was probable; if it had been almost impossible, no.

Here's the point: an open option —the wall that moves— has value when the future is uncertain and the change is fairly probable, but it costs a premium that's wasted if the change doesn't come. The mastery isn't "make all the walls movable" (over-engineering: you'd pay the premium in the whole house, even where you'll never reconfigure) nor "make everything concrete" (under-engineering: cheap today, very expensive the day you want to change); it's knowing which walls are worth leaving movable —those in the areas where you'll probably reconfigure— and which to fix. In Mercado, a "movable wall" is an abstraction over the payments provider, an interface between catalog and orders, a contract that lets a piece be swapped. This lesson gives you the calculator to decide which to leave movable: the option's break-even point.

Worked example: the value of an option and its break-even point

We're going to put a number on the value of an open door. We model a Mercado decision facing an uncertain change —one that can come with probability p—, and compare two stances:

  • rigid — doesn't buy the option. Pays nothing upfront (saves the premium). But if the change comes, it has to pay the full rework: rewrite, because nothing was postured to move. It's the concrete house.
  • flexible — buys the option. Pays a premium upfront (builds the seam, the abstraction, the movable wall) and, if the change comes, only pays a cheap adaptation through that seam. It's the light-walls house.

The expected cost of each stance depends on the change's probability. rigid pays nothing unless the change comes, and then pays dearly: its expected cost is p × full_rework. flexible pays the premium always, and if the change comes pays a small adaptation: its expected cost is premium + p × adaptation. The crossover between those two lines is the break-even point: the probability above which buying the option comes out cheaper than risking a rewrite.

# Optionality: keeping an option open has VALUE when the future is uncertain,
# even if you never exercise it. An unforeseen change can come with probability p.
#   rigid    : pays nothing upfront; if the change comes, pays the FULL rework
#              (rewrite, because nothing was designed to move).
#   flexible : pays a PREMIUM upfront (a seam/abstraction that leaves the
#              door open) and, if the change comes, only pays a cheap adaptation.
FULL_REWORK     = 80000  # R: rebuild from scratch if there was no seam
ADAPT_THRU_SEAM = 8000   # A: adapt through the seam if there was one
OPTION_PREMIUM  = 6000   # C: what it costs to build the seam upfront


def expected_rigid(p):
    return p * FULL_REWORK


def expected_flexible(p):
    return OPTION_PREMIUM + p * ADAPT_THRU_SEAM


breakeven = OPTION_PREMIUM / (FULL_REWORK - ADAPT_THRU_SEAM)

print(f"{'p(change)':>10}{'rigid':>12}{'flexible':>12}   who wins")
print("-" * 52)
for p in [0.05, 0.10, 0.20, 0.40, 0.60]:
    r = expected_rigid(p)
    f = expected_flexible(p)
    winner = "flexible" if f < r else "rigid"
    print(f"{p:>10.2f}{r:>12,.0f}{f:>12,.0f}   {winner}")
print("-" * 52)
print(f"Break-even point: p = {breakeven:.3f} ({breakeven * 100:.1f}%).")
print(f"BELOW {breakeven * 100:.1f}% probability, the option's premium is")
print("wasted (rigid wins): building the seam would be over-engineering.")
print("ABOVE it, the option is worth its premium: the change is probable enough")
print("that leaving the door open comes out cheaper than rewriting.")

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

 p(change)       rigid    flexible   who wins
----------------------------------------------------
      0.05       4,000       6,400   rigid
      0.10       8,000       6,800   flexible
      0.20      16,000       7,600   flexible
      0.40      32,000       9,200   flexible
      0.60      48,000      10,800   flexible
----------------------------------------------------
Break-even point: p = 0.083 (8.3%).
BELOW 8.3% probability, the option's premium is
wasted (rigid wins): building the seam would be over-engineering.
ABOVE it, the option is worth its premium: the change is probable enough
that leaving the door open comes out cheaper than rewriting.

Read the table top to bottom, following which stance wins in each row, because the change of winner is the whole argument.

With p = 0.05 (5% probability), rigid wins. The change is so improbable that paying the premium of 6000 for the option isn't recovered: rigid costs 4000 expected (5% of risking the 80000) against flexible's 6400. Here, buying the option would be throwing money away —the light-walls house for a layout you almost surely won't change—. This is the over-engineering territory: below the break-even point, leaving the door open is waste.

From p = 0.10 (10%) on, flexible wins, and the advantage grows fast. With 10%, flexible costs 6800 against rigid's 8000 —the option already pays—. With 40%, the difference is brutal: 9200 against 32000. With 60%, 10800 against 48000. Notice the pattern: the cost of flexible grows slowly (from 6800 to 10800 when p goes from 10% to 60%), because every time the change comes it only pays the cheap adaptation. The cost of rigid grows fast (from 8000 to 48000), because every time the change comes it pays the full rework. The more probable the change, the more obvious the advantage of having bought the option.

And in the middle is the number that makes all this useful: the break-even point, p = 8.3%. That 8.3% isn't an opinion; it comes from the formula premium / (rework − adaptation) = 6000 / (80000 − 8000). Below 8.3% probability, don't buy the option (rigid wins). Above it, buy it (flexible wins). That threshold is the tool this module gives you so as not to argue "flexibility" in the abstract: facing any uncertain change, you estimate its probability, compare it with the break-even point, and decide. Optionality stops being a vague virtue and becomes a calculation.

Notice what the break-even point reveals about the module's two abysses, because it unites them in a single line. Over-engineering is buying options below their break-even point —paying premiums for changes too improbable—. Under-engineering is not buying options above their break-even point —refusing to pay a cheap premium for a fairly probable change, and paying the full rework when it comes—. The architect who designs for change isn't "the one who leaves many doors open" nor "the one who leaves them all closed"; it's the one who buys every option whose probability exceeds its break-even point, and no other. Lessons 5, 6, and 7 develop each side; this lesson gave you the line that separates them.

As lines, the crossover looks like this:

Expected cost (USD) by the change's probability
 48,000 |                                    rigid /
        |                                   /
 32,000 |                            /
        |                     /
 16,000 |              /
  8,000 |        /  ......................... flexible (grows slowly)
        |___/____:_______________________________________
        0%    8.3%    20%      40%      60%   -> p(change)
          rigid wins |  flexible wins
          (over-eng  |  (leaving the door open pays for itself)
           buy       |
           here)     |

Deep dive: optionality as insurance, and its premium

It's worth making the analogy with finance and insurance explicit, because it clarifies why optionality isn't the same as "flexibility" plainly and why it has a price that must be respected.

A financial option is the right to buy or sell something at a fixed price in the future, without the obligation to do so. It's worth money because it gives you the possibility of reacting if the world moves in your favor, protecting you if it moves against you. And it costs a premium upfront: you pay today for the right to decide tomorrow with more information. Insurance is the same structure: you pay an annual premium for the right to be covered if the uncertain event occurs (the fire, the crash). No one buys insurance expecting to collect it; they buy it for the value of being covered against uncertainty. If the event doesn't occur, the premium is "lost" —but it wasn't a mistake to pay it, it was the price of not being exposed to an improbable but expensive catastrophe—.

In architecture, a seam is an option and its construction cost is the premium. Leaving an abstraction over the payments provider is buying the option to change providers cheaply; the premium is the extra effort of designing that abstraction today. If you never change providers, the premium was "lost" —but, just like insurance, it wasn't necessarily a mistake: it depended on the probability—. Here's the discipline that separates the mature architect from the one who only repeats "be flexible": an option is only worth it if its premium is less than the expected value of the protection it gives, and that depends on three measurable things —how probable the change is (p), how expensive it would be without the option (the full rework), and how expensive the premium is (building the seam)—. The break-even point is exactly where those three balance.

This explains why "always be flexible" is bad advice, as bad as "never be flexible". Buying all the options —leaving all the walls movable, abstracting everything, making everything configurable— is like insuring your house against a meteorite strike, a tsunami in the desert, and a dragon attack: you pay a lot of premiums for events that aren't going to occur, and the cost of all those premiums together ruins you, even though each individual "just in case" insurance sounds prudent. That's the over-engineering, and lesson 5 measures it. The discipline of optionality isn't buying many options; it's buying the right options —those whose probability of being exercised exceeds their break-even point— and leaving the rest closed. The architect doesn't maximize flexibility; they maximize the expected value, which is a very different thing.

A nuance on honest uncertainty. The break-even point depends on estimating p, the change's probability, and those estimates aren't exact —no one knows precisely whether Mercado will open a second country next year—. But this doesn't invalidate the tool; it makes it more useful. Even if you don't know p to the decimal, you can almost always say whether it's clearly above or clearly below the break-even point. If the business is already talking about expanding to another country, the probability of needing multi-currency is well above 8.3% —buy the option, no precision needed—. If someone proposes abstracting the system "in case someday Mercado becomes a social network", that's well below —don't buy it—. The tool doesn't ask you to guess exact p; it asks you to place it relative to a threshold, and that can almost always be done. The break-even point turns an argument of opinions ("we should be flexible" / "let's not complicate it") into a comparison with a number.

Common mistakes

Buying the option below its break-even point. What happens: the architect leaves a door open —an abstraction, a configuration layer, a seam— for a change so improbable that the premium is never recovered; they build the movable wall in an area of the house they'll never reconfigure. Why it happens: "leaving the door open" always sounds prudent, and each individual "just in case" option seems cheap and sensible; the cost appears when many are summed. How to spot it: if on asking "how probable is this change really?" the honest answer is "almost never, but just in case", you're buying below break-even. How to fix it: estimate the change's probability and compare it with the break-even point; if it's clearly below, don't buy the option —that's the YAGNI discipline lesson 5 develops—. In the example, with p = 5%, rigid wins (4000 vs 6400): buying the option there is throwing away the premium.

Not buying the option above its break-even point. What happens: the architect refuses to pay a cheap premium for a fairly probable change —"let's not complicate it, let's do it directly"— and when the change comes, pays the full rework; they fixed everything in concrete in an area they were going to reconfigure. Why it happens: the premium looks like unnecessary complexity in the moment, and "making it simple/direct" sounds virtuous; the rework cost is future and invisible. How to spot it: if on asking "and if this probable change comes, how much does it cost?" the answer is "very expensive, it would have to be rewritten", and the change is probable, you didn't buy an option you should have. How to fix it: pay the cheap premium for the options whose probability exceeds break-even —that's the seam that avoids painting into a corner, lesson 6—. In the example, with p = 40%, not buying the option costs 32000 against 9200: refusing the 6000 premium was very expensive.

Confusing "optionality" with "maximizing flexibility". What happens: the architect understands that options have value and concludes "so let's make everything flexible" —everything abstract, everything configurable, everything swappable—, without noticing that each option costs a premium and that buying them all ruins the complexity budget. Why it happens: optionality is read as a virtue to maximize, not as an expected-value calculation to optimize. How to spot it: if the system has abstractions and indirections everywhere, most with a single real use case, you maximized flexibility instead of value. How to fix it: remember that the architect doesn't maximize options, they maximize the expected value —buy only the options whose probability exceeds their break-even point—. Insuring the house against dragons is prudent per individual option and ruinous in aggregate. Well-understood optionality is selective by definition.

Exercises

Exercise 1 — Buy the option? For each of these uncertain changes in Mercado, say whether you'd buy the option (leave the seam) or not, comparing by eye the change's probability with the break-even-point idea, and justify: (a) abstract the payments provider, when finance is already negotiating with a second provider for next quarter; (b) leave the catalog system prepared to support products in 40 languages, when Mercado operates only in one Spanish-speaking country and there are no expansion plans; (c) leave an interface between orders and shipping instead of a direct call, when the team already knows shipping is going to be extracted into a service next year.

See solution

  • (a) Buy the option (leave the payments abstraction). The change's probability is very high —finance is already negotiating the second provider for next quarter—, well above any reasonable break-even point. The premium of abstracting the provider is cheap compared to the rework of adding a second provider to a system that assumed a single one. It's exactly the high-p case where flexible wins by a landslide. Buy the option.

  • (b) Don't buy the option (don't prepare the 40 languages). The probability is very low —one Spanish-speaking country, no expansion plans—: supporting 40 languages is insuring the house against a tsunami in the desert. The premium (the complexity of a full internationalization system) would be wasted because the change almost surely doesn't come. It's well below the break-even point. Don't buy it —that's over-engineering (lesson 5)—. Note the nuance: you don't need to know exact p; it's enough to see it's clearly below the threshold.

  • (c) Buy the option (leave the interface). The team already knows shipping is extracted next year: the probability is practically 1. The premium of leaving an interface instead of a direct call is minimal, and it avoids the rework of untangling a direct call when shipping becomes a network service. Well above break-even. Buy the option —this is the seam that avoids painting into a corner (lesson 6)—.

The pattern: (a) and (c) are probable changes → buy the option; (b) is improbable → don't buy it. The tool doesn't ask you to guess exact probabilities, only to place them relative to the threshold, and in the three cases that can be done clearly.

Exercise 2 — Move the break-even point. The example's break-even point is 8.3%, with a premium of 6000, a rework of 80000, and an adaptation of 8000. Without running code, reason what happens to the break-even point (up or down) in each case, and what it means in terms of when it's worth buying the option: (a) the premium of building the seam rises to 30000 (a very complex abstraction); (b) the full rework rises to 200000 (a change that would touch half the system).

See solution

The break-even-point formula is premium / (rework − adaptation).

  • (a) Premium rises to 30000. The break-even point rises: 30000 / (80000 − 8000) = 30000 / 72000 = 0.417, that is 41.7%, against the original 8.3%. Meaning: when the option is expensive to build, the change has to be much more probable (41.7% instead of 8.3%) for buying it to be worth it. An expensive seam is only justified for fairly certain changes. This is intuitive: paying a high premium for insurance only makes sense if the event is fairly probable. Many "flexible" seams aren't worth it not because the change is improbable, but because the seam itself is too expensive —and then the rigid stance is better, rewriting if it ever comes—.

  • (b) Rework rises to 200000. The break-even point drops: 6000 / (200000 − 8000) = 6000 / 192000 = 0.031, that is 3.1%, against the original 8.3%. Meaning: when rewriting without the option would be catastrophically expensive, buying the option is justified even for fairly improbable changes (3.1% probability is enough). It's the logic of catastrophe insurance: even though the fire is improbable, the premium is worth it because the damage without coverage would be ruinous. For huge-impact changes, the threshold for "leaving the door open" is very low.

The lesson of the two cases: the break-even point isn't a fixed number; it depends on the premium and the impact. Cheap seams that protect against enormous reworks are almost always justified (very low threshold); expensive seams that protect against modest reworks almost never (very high threshold). That's why optionality is a calculation, not a virtue.

Exercise 3 — The dragon insurance. A Mercado architect defends an enormous abstraction layer by saying: "it's always good to leave doors open, you never know what's going to happen". Using the insurance analogy and the expected-value idea, explain why "it's always good to leave doors open" is a wrong principle, and how the discipline of optionality would reframe it.

See solution

"It's always good to leave doors open" is wrong for the same reason "it's always good to have more insurance" is wrong: each open door costs a premium, and buying premiums without looking at the event's probability ruins you. Insuring your house against fire (probable, catastrophic) is prudent; insuring it also against meteorites, desert tsunamis, and dragon attacks is ruinous —you pay a lot of premiums for events that aren't going to occur—, even though each individual "just in case" insurance sounds sensible. An enormous "just in case" abstraction layer is architecture's dragon insurance: each indirection it adds has a cost (complexity, premiums), and buying them all without evaluating probabilities produces an expensive and tangled system whose flexibility no one uses. That's the over-engineering lesson 5 measures.

The discipline of optionality reframes it like this: the architect doesn't maximize open doors; they maximize the expected value. Facing each possible seam, they ask three measurable things —how probable is the change (p)? how expensive would the rework be without the seam? how expensive is the premium of building it?— and buy the option only if its probability exceeds the break-even point (premium / (rework − adaptation)). That turns "you never know what's going to happen" —which sounds like wisdom but is an excuse not to think— into a concrete decision: for this change, with this estimated probability, does the premium pay for itself or is it thrown away? Sometimes yes (buy the door), sometimes no (leave it closed, rewrite if it ever comes). "Always" and "never" are the two ways of not doing the math.

Summary and next step

In this lesson you installed the second piece of the stance: optionality, the value of keeping the doors open under uncertainty. You saw, with the movable-walls house against the concrete one, that an open option has value even if you never exercise it —like insurance— but that it costs a premium that's wasted if the change doesn't come. And you measured it: comparing the rigid stance (rewrite if the change comes) with the flexible one (pay the premium and adapt cheaply), you found the break-even point at 8.3% —below it, the option is wasted (over-engineering); above it, it pays for itself—. You learned that that threshold unites the module's two abysses in a single line, that optionality isn't "maximizing flexibility" but "maximizing expected value", and that the tool doesn't ask you to guess exact probabilities, only to place them relative to the threshold.

Before moving on you should be able to: explain why an option has value even if it isn't exercised, and why it costs a premium; compute by eye whether an uncertain Mercado change is above or below its break-even point; and refute both "always be flexible" and "never complicate it" with the expected-value argument.

Lesson 4 takes the third piece of the stance, and it's the most counterintuitive: sacrificial architecture. Sometimes the best way to handle uncertainty isn't to keep a door open, but to knowingly build something you're going to throw away —a disposable prototype that validates the real requirements and then gets replaced—. You'll see why that isn't waste but investment, and execute when the prototype comes out cheaper than building "in one go". With numbers, so that "build it to throw it away" stops sounding like heresy and becomes a measurable decision.

Resources

  • Michael Feathers, Working Effectively with Legacy Code (Prentice Hall, 2004) — the book that popularized the concept of seam: the point where you can alter a system's behavior without editing in that place. The seam as an architectural option in this lesson comes from there. In English.
  • Chris Matts and Olav Maassen, "Real Options Underlie Agile Practices" (InfoQ, 2007) — infoq.com/articles/real-options-enhance-agility. The text that brought real-options theory to software: an option has value, costs a premium, and shouldn't be exercised ahead of time. The economic basis of this lesson. In English.
  • Andrew Hunt and David Thomas, The Pragmatic Programmer, 20th Anniversary Edition (Addison-Wesley, 2019), topic "Reversibility" — on why good software keeps options open and avoids the decisions that close doors expensively. In English. The mechanics of classifying decisions by their reversibility (one-way/two-way doors) is the sister guide architecture-decisions.
  • Martin Fowler, "Yagni" (2015) — martinfowler.com/bliki/Yagni.html. The indispensable complement: why buying options below their break-even point (building for improbable futures) is the over-engineering error, which lesson 5 develops. In English.
← PreviousThe architecture is never finalNext →Sacrificial architecture