In emergent design, which decisions must still be made deliberately up front, and how do you decide?

### The framing that answers this well Emergent design is not a claim that every decision is equally cheap to defer. It is a claim about one particular class of decision: **structure that a later restructuring can reach.** The right question to ask about any decision is therefore not "is it design?" but **"can the refactor step get to this later, and what does it cost if I am wrong?"** Two properties decide it: * **Reversibility.** What does undoing this cost once there is production data, other teams, and a running system? Class shapes and module internals cost hours. A persisted data shape costs a migration. A boundary between processes costs a project. A published contract costs other people's calendars. * **Reachability.** Can it be changed inside code you own, in a series of commits that each keep the suite green? If yes, let it emerge. If changing it requires coordinating with someone else's release, or rewriting stored history, no amount of refactoring discipline will produce it. ### What does not emerge In practice the short list is stable: * **The shape of persisted data and its history.** Emergence rewrites code; it does not rewrite what you already stored. * **Process and deployment boundaries.** Splitting one unit into two is a refactoring; splitting one service into two is a project, because the calls between them become failures. * **Contracts consumed by other teams or external clients.** You can refactor behind them; you cannot unilaterally reshape them. * **Cross-cutting decisions that will be threaded through hundreds of call sites.** The time source is the classic one. In a marketplace bidding engine, "whose clock decides bid order" is a choice that touches ordering, auto-extend, audit and expiry. Left to emerge, each area quietly makes its own choice, and at a 1,200-request-per-minute peak the disagreement shows up as bids stamped seconds in the future winning ties they did not win. Retrofitting one clock authority afterwards is not an extraction; it is an audit of every call site plus a data-quality problem in what was already recorded. * **Constraints imposed from outside the code** — regulatory retention, tenancy isolation, the security boundary. These are requirements, and they are cheaper as constraints than as discoveries. ### How I would actually run it Decide the smallest set of those deliberately, up front, as a thin skeleton — the boundaries, the stored shapes, the external contracts, the two or three cross-cutting authorities — and then leave everything inside them to emerge. The skeleton is intentionally thin: every item on it is a decision made with the least information you will ever have, so each additional item is a bet. Then treat each up-front decision as a hypothesis rather than a settlement. Write down the decision, the alternative you rejected, and the observation that would make you revisit it, and put a real trigger on it — a load level, a second consumer appearing, a third variation of a rule. Teams that skip this half end up defending a day-one decision for years because nobody remembers it was provisional. ### The organisational half, which is what makes it a lead's question Emergent design has preconditions that are social, not technical, and a principal-level answer names them: * It assumes **everyone refactors continuously.** Where the restructuring beat is the first thing dropped under delivery pressure, structure does not emerge — debt does. That has to be a stated policy with visible slack, not an aspiration. * It assumes a **shared design bar.** Emergence is a sequence of judgement calls; if five people hold five different bars, the result is five local optima that fight. Pairing, review, and regular design conversations are the mechanism, not decoration. * It **does not compose across teams.** Inside a team's own code it works well. Across an ownership boundary nobody can refactor both sides in one commit, so the boundary must be designed and the contract stated. This is the main reason "let it emerge" scales badly upward. * It is **weaker in unfamiliar territory.** In a legacy area with no suite, or a domain nobody on the team has modelled before, the first structures are guesses either way; there the honest move is a timeboxed spike to buy information, then decide. ### The trap to avoid on both sides One failure is treating everything as emergent, discovering at scale that the stored shape and the time authority were never decided, and paying for it in migrations. The opposite failure is concluding that because some decisions are irreversible, all of them must be settled up front — that is how you get an architecture document that specifies class names for code nobody has written. The skill is drawing the line in the right place and saying out loud why each item is on the short side.