skip to content

How do you tell whether an emerging design is converging, and what do you do when repeated refactoring stops improving it?

level: seniorimportance: nice to knowfreq 21%

answer

  1. Watch the trend, not a number
  2. Smaller and rarer versus the same shape returning
  3. Improving one place worsens another
  4. Green proves behaviour, never structure
  5. Not-yet-extracted versus not reachable from here

basics

~20 s

Convergence shows as restructurings getting smaller and rarer while changes stay local. When the same duplication keeps returning and small features touch many files, the missing structure is bigger than a restructuring step can reach and needs a deliberate decision.

solid answer

~50 s

I watch a small set of trends rather than a metric. Converging looks like: restructurings shrinking, new features landing as new units plus a line of wiring, arrangement per test flat, and names matching the words the domain experts use. Accreting looks like: the same duplication reappearing in a slightly different shape, every new test adding a branch to the same conditional, and restructurings that improve one place by making another worse — the sign that the resolving structure is not reachable from where you are. When it stalls I stop and name the missing concept in domain words, spike the target shape on a throwaway branch, then convert it into a series of green steps: add the new shape beside the old, migrate callers in small commits, delete the old one. A green suite is not evidence the design is fine — emergence only reveals what the tests exercise.

code

pseudocode · 13 lines
pseudocode
# 37 existing cases all looked like this
test "higher bid wins":
    clock = TestClock(at: "2026-04-11T10:14:03Z")
    a = bid(amount: 40.00, stampedAt: "2026-04-11T10:14:03Z")
    b = bid(amount: 40.40, stampedAt: "2026-04-11T10:14:03Z")
    assert winner(a, b) == b

# the case nobody wrote: two clocks disagree
test "a client stamp ahead of the receiving clock does not win the tie":
    clock = TestClock(at: "2026-04-11T10:14:03Z")
    early = bid(amount: 40.40, stampedAt: "2026-04-11T10:14:01Z", received: "10:14:03")
    ahead = bid(amount: 40.40, stampedAt: "2026-04-11T10:14:04.8Z", received: "10:14:03")
    assert winner(early, ahead) == early    # fails: client stamp is trusted for ordering

go deeper

for a junior

You are unlikely to be asked this, but know the headline: passing tests say the behaviour you wrote down still works, and say nothing about whether the structure is good. Those are separate questions.

for a middle

Be able to name a few concrete signals that a design is drifting — the same duplication reappearing, arrangement growing every sprint, a small feature touching many files — rather than relying on a general feeling.

for a senior

An interviewer expects lived experience: describe the trends you watch, how you separate a missing extraction from a decision you cannot refactor into, and the staged migration you would run under a green suite.

for a principal

Own the escalation. Say how you decide that a stalled design needs a deliberate decision rather than more cycles, how you fund that work against delivery, and how you keep the team's judgement about it calibrated.

### What "converging" means here Emergent design promises that repeated small restructurings accumulate into a coherent structure. That promise is not automatic, and a senior engineer is expected to be able to tell the two states apart: a design that is settling, and one that is merely accreting while the suite stays green. **Signals of convergence.** Restructurings get smaller and rarer. New features land mostly as new units plus a line of wiring. The names in the code start matching the words people use in the domain conversation. Test arrangement per case is flat or shrinking. A change that sounds local *is* local. **Signals of accretion.** The same duplication keeps reappearing in a slightly different shape and you keep failing to name it. Every new test adds a branch to the same conditional. Arrangement grows monotonically. A one-sentence feature touches seven files. And the tell that matters most: restructurings that improve one place by making another worse — you are moving the problem around because the structure that would resolve it is not reachable from here. ### Why a green suite is not evidence of a good design The suite pins the behaviour you thought to write down. It is silent about everything else, which means emergence only reveals problems that the tests exercise. Concretely: a bidding engine grew over 37 tests with every case constructing bids at a fixed instant. Ordering, reserve prices and auto-extend all emerged cleanly under that assumption. In production at a 1,200-request-per-minute peak, bids carried client-supplied timestamps whose clocks drifted; a bid stamped 1.8 seconds in the future sorted ahead of one that actually arrived earlier, and the auto-extend window opened against a time nobody owned. No refactoring would ever have surfaced this, because no test ever expressed disagreement between two clocks. The missing structure — one authority for time, and a rule that a client-supplied instant is untrusted input to be validated, not a fact — is a decision, not an extraction. That is the general shape: **emergence surfaces what the tests exercise; it cannot surface an assumption every test shares.** ### What you actually do when it stops improving 1. **Name the missing concept explicitly.** Stop refactoring and write down, in domain words, what the recurring duplication is an instance of. Half of stalled emergence is a naming failure: the extraction is reachable, but nobody has said the word yet. 2. **Spike it, throw the spike away.** Explore the target structure on a scratch branch without the obligation to keep it. This is exploration, not delivery, and its output is a decision. 3. **Convert the big move into a series of green steps.** A large restructuring is still done under the suite: add the new shape beside the old, migrate callers in small commits, delete the old one. The size of the destination does not license leaving the suite red for two days. 4. **Add the test that expresses the missing disagreement.** For the clock case, that is a case where two sources of time disagree — write it, watch it fail, and the structure is drivable again. 5. **Escalate the decisions emergence cannot reach.** A stored data shape, a boundary between processes, or a contract another team consumes will not fall out of a refactor step. Recognising which of the five you are in is most of the skill. ### The judgement being tested Interviewers use this to separate someone who applies the cycle mechanically from someone who monitors whether it is paying. The weak answer keeps applying five-minute refactorings to a problem that needs a decision, and points at the green suite as evidence that things are fine. The strong answer says what a stalling design looks like, distinguishes "not yet extracted" from "not reachable from here", and picks a proportionate response — usually a spike plus a staged migration, not a rewrite and not another week of nibbling. It is worth being candid that no metric settles this. Coverage does not; it is unchanged by a bad structure. Churn and change-locality trends are weak evidence at best. The reliable instrument is the trend in effort per change, observed by the people making the changes — which is why teams that practise this discuss the design regularly rather than waiting for a number to tell them.

  • Why can a suite be fully green and steadily growing while the design quietly gets worse?
    Because the suite pins the behaviour someone thought to write down and is silent about everything else. If every case shares an assumption — one source of time, one tenant, one currency — no restructuring will ever surface a problem in that assumption, because nothing in the suite disagrees. Emergence reveals what the tests exercise; a shared blind spot is invisible to it by construction.
  • How do you distinguish "not yet extracted" from "not reachable by refactoring at all"?
    Ask whether the change can be made in code you own, in a series of commits that each keep the suite green. If yes, it is an extraction you have not made yet, usually because nobody has named the concept. If it requires rewriting stored data, moving a boundary between processes, or coordinating another team's release, no amount of restructuring discipline will produce it — that is a decision with a migration attached.
  • Is a rewrite ever the right response to a stalled emergent design?
    Rarely, and almost never as the first move. The proportionate response is a throwaway spike to establish the target shape, then a staged migration: build the new structure alongside the old, move callers a few at a time under a green suite, delete the old one. The destination being large does not license leaving the suite red for days, which is what makes a rewrite risky rather than its size.

saying these in an interview costs you the question

  • Treats a green suite as evidence the design is fine
  • Keeps nibbling with small refactorings at an unreachable problem
  • Declares the design finished when coverage stops moving
  • Stops delivery for a multi-week rewrite instead of staged steps
  • Assumes emergence surfaces assumptions no test exercises
  • Leaves the suite red for days during a large restructuring

context

resolving links…