Constraint-First Design: Naming the Binding Constraint · the method
This is the first one, and it installs the move the whole course rests on. Before any architecture, you name the single constraint the design exists to relieve — then derive every decision from it. The grade is in the reasoning, not in finding a famous system: a clean derivation chain on a humble system beats a vague gesture at a clever one.
Time: ~45–60 min · Due: before Module 2 · Submit: post your write-up in the cohort channel.
Pick one system that must deliver a capability within a hard performance, memory, latency, or time budget — something you've built, used, or can reason about concretely.
⚠️ The typeahead search box derived below is off-limits as your submission — it's the worked demo. Pick something else.
In a ~300–400 word write-up, make the five moves:
- Name the binding constraint — in one sentence. The single force that forbids the obvious build. If it takes a paragraph, you haven't found it yet. It is not a requirement and not a feature.
- Tension or conjunction? Is it one good traded against another (optimise the trade), or several goods demanded together and met by one idea (hunt for the unifying mechanism)?
- Choose the most restrictive model that still does the job. The representation that makes the hot path cheap — not the most general one you could defend in review.
- Trace three decisions back to the constraint as a chain: constraint → structure → mechanism → implementation. Each step a consequence of the last.
- Name exactly what the restriction forbids — the generality you gave up — and what it bought. That sentence is the honest cost of the design.
- A time you reached for a general model and optimised later — what did premature generality cost you?
- A restriction you first saw as a wall that turned out to be a strength — what did the limit buy?
- A constraint you've met that was a conjunction — one idea that delivered several goods at once. What was the idea?
Reply to one classmate's audit. Find a decision in their design that doesn't trace back to their named constraint (that's decoration), or a more restrictive model that would have made their hot path cheaper — and propose it.
Everything below is just these, applied to one system. Keep them in front of you:
- Name the binding constraint first. One sentence, before any structure. It's the force that forbids the naive build — not the feature list.
- Know the shape. Tension → optimise a trade. Conjunction → find the one idea that delivers everything at once.
- Pick the most restrictive model that still works. Generality costs speed; a chosen restriction buys it back.
- Derive, don't decorate. Every decision is a consequence of the constraint, or it's suspect. The chain is the argument.
- Name what the restriction forbids. State the generality you gave up and what it bought — that's the honest cost.
Let's run the method on something that is not your assignment: a typeahead search box — suggestions appearing as the user types, in a browser, on a mid-range laptop. Watch the moves, then make them on your own system.
1 · Name the binding constraint. Not "users want suggestions" — that's a requirement. The binding constraint is: every keystroke must return ranked suggestions in under ~16 ms, or the box feels laggy. One sentence. That latency budget is the force that forbids the obvious build (run a fresh search over the whole corpus on every keystroke). Everything downstream bends around it.
2 · Tension or conjunction? It's mostly a tension: suggestion quality (search everything, rank richly) traded against latency (answer in 16 ms). Naming the shape tells me my job is to find the best point on that line — not to hunt for a single magic mechanism.
3 · Choose the most restrictive model. The most general model — full-text query per keystroke — blows the budget. The most restrictive representation that still does the job is a precomputed prefix structure (a trie, or a sorted prefix map) built once, offline. It can't answer arbitrary queries — only "what completes this prefix?" — and that restriction is exactly the point: it makes the only operation I need cheap.
4 · Derive the chain. constraint (16 ms/keystroke) → structure (prefix trie, precomputed) → mechanism (walk to the prefix node, read the top-N precomputed completions) → implementation (cap results, debounce input, cache the last node). Each step is forced by the one before it. Nothing here was chosen because it was familiar.
5 · Name what the restriction forbids. The trie forbids arbitrary mid-word and fuzzy matching — I gave up general query power. What it bought: a hot path that's a pointer-walk instead of a search, comfortably inside 16 ms. That's the honest cost, stated in one sentence.
Notice what just happened: I named one constraint, classified its shape, picked the most restrictive model that still worked, derived a chain where every step traces back, and named what the restriction cost. That's the whole of Part A. Your job is to make those five moves on your system.
The chain runs left to right: the binding constraint forces a structure, which forces a mechanism, which forces an implementation. The dotted arrow back is the test — if a decision doesn't trace home to the constraint, it's decoration.
flowchart LR
C(["BINDING CONSTRAINT<br/>16 ms per keystroke"])
S["Structure<br/>precomputed prefix trie"]
M["Mechanism<br/>walk to node, read top-N"]
I["Implementation<br/>cap · debounce · cache"]
D{{"forbids: arbitrary<br/>+ fuzzy queries"}}
C ==> S ==> M ==> I
I -. "does every step trace back?" .-> C
C --- D
style C stroke:#F5A623,stroke-width:2px
style D stroke:#C97E12,stroke-width:1.5px
Copy this into your doc and replace each blank. Keep it tight — most of the marks are in the chain (point 4) and the honest cost (point 5).
SYSTEM (one line): _______________________________________
1. BINDING CONSTRAINT (one sentence)
The single force that forbids the obvious build: _______
2. SHAPE
Tension or conjunction? _____________________________
So my job is to: ____________________________________
3. MOST RESTRICTIVE MODEL
Representation chosen: ______________________________
Why it makes the hot path cheap: ____________________
4. DERIVATION CHAIN
constraint -> ______________________________________
-> ______________________________________
-> ______________________________________
(each step a consequence of the last)
5. WHAT THE RESTRICTION FORBIDS
Generality given up: ________________________________
What it bought: _____________________________________
If you want a diagram, copy the Mermaid block above and relabel it for your system — it renders as a flowchart in your Gist.
Part B — starter prompts (answer in your own words; don't just restate these):
- Find a project where "let's keep it general for now" quietly became the design. What did that generality cost when the budget finally bit?
- Recall a limit you resented — a tiny memory ceiling, a hard deadline, a locked-down platform — that ended up shaping the best part of the design. Name what it bought.
- Separate "trade one good for another" from "one idea delivers several goods." Find a real case of the second — and name the single idea that did the work.
- Writing a requirement instead of a constraint. "It must support search" is a requirement. "Every keystroke must answer in 16 ms" is the binding constraint. Only the second one forbids a build.
- A constraint that takes a paragraph. If you can't say it in one sentence, you've bundled several forces — find the one everything else bends around.
- Decoration in the chain. A step that's there because it's familiar, not because the last step forced it. If it doesn't trace back, cut it or justify it.
- Reaching for the general model. "I picked the flexible one so I can extend it later" is premature generality — the exact anti-pattern. Pick the most restrictive model that still works.
- Skipping the cost. A design with no named cost is a design you haven't been honest about. State what the restriction forbids.
- Names the binding constraint before any structure — in one clean sentence.
- Classifies the shape (tension vs conjunction) and lets it direct the search.
- Chooses the most restrictive model that still works, not the most general.
- Shows a derivation chain where all three decisions trace home to the constraint.
- Is honest about what the restriction costs — names the generality given up and what it bought.
That's the method. Five modules from now you'll have run this same move on representation, consistency, scale, and delivery — but it always starts here: name the constraint first, then derive.