Hints for Computer System Design — CS Papers Deep Read Paper 70

What did this paper do?

In 1983 Butler Lampson — one of the people behind the first personal computer (the Alto), Ethernet, and the first what-you-see-is-what-you-get text editor — compressed twenty years of system building into about thirty short, sloganized lines.

The paper isn't about how to write code. It's about how to decide when there is no right answer: should this feature exist, should anyone else be able to see it, what happens when it breaks. Most of the things engineers say to each other today — "don't over-engineer it," "make it right before you make it fast," "shed load when you're drowning" — trace back to this one page.

First, a curiosity

He didn't call them rules, and he didn't call them laws. He called them hints. And in this very paper, "hint" is also a precise technical term: a guess that may be wrong, but whose correctness can be checked very cheaply.

So the title is its own instruction manual: every line here might be wrong for your project, so go check it yourself. A classic that would go on to be cited thousands of times opens by disclaiming its own authority — which is exactly why it hasn't aged.

What was new

Papers of that era either proved things about algorithms or described a system someone built. Nobody wrote about judgment — judgment lived in the heads of old hands and got transmitted by apprenticeship and by wrecking projects. Lampson wrote it down, with examples on both sides, including failures he was part of.

How it works

He first collapses every design argument onto two axes: what you're worried about (is it right, is it fast enough, what happens when it breaks) and where you're deciding (how much to do at all, what the interface exposes, how the insides work). Three by three, nine boxes, and the hints all find a home. Three of them, for flavor:

1. Do one thing and do it well; don't rush to generalize. Making something "general" is a bet on future requirements, and everyone pays for a lost bet: a bloated interface that also runs slower. A handy paring knife turned into a Swiss army knife peels apples worse. Want to reuse a good idea? Use it again, separately, in each place — don't build one universal part.

2. Don't hide power. Encapsulation exists so you needn't look at what you don't want to see — not to lock away the capability you actually need. An automatic transmission shifting for you is great; one that won't let you touch the brake means you'll go build your own car. An interface that hides too much always gets bypassed in the end.

3. Send the normal case and the worst case down separate paths. They want opposite things: the everyday path must be fast, while the disaster path only has to make some progress. Force them into one path and you get neither. It's why hospitals separate the clinic from the emergency room — mixed together, the sore throat and the cardiac arrest drag each other down.

What it led to

This page became required reading in generations of systems courses, common knowledge in interviews, and shorthand in design reviews — it isn't cited so much as memorized and used. One honest cost: these are experience, not laws, and they contradict each other, while the paper gives you no way to arbitrate. Usually only someone who has already been burned knows which one applies right now.

Remember one thing

A man who helped build the first personal computer wrote down the judgment behind "get it right, make it fast, keep it working" as about thirty memorable lines — and honestly called them hints: they may be wrong, please check. Most of the design common sense engineers repeat today starts on this page.

Want the 3×3 table, the precise mechanism of a hint, and which lines the decades have rewritten? → Switch to the deep read

In one sentence

Lampson distilled the lessons that kept recurring across a set of real systems he helped design — successes and failures alike — into about thirty sloganized "hints," organized by a 3×3 table (three questions: functionality / speed / fault-tolerance, against three places: how much to do / the interface / the implementation). It proves no theorem, yet it became the most widely circulated checklist of judgment in system design — and he deliberately called them hints rather than rules: they may be wrong, verify for yourself.

Glossary

Interface: the contract a module offers outward — what you may ask it to do and what it promises. Users (clients) see only this, never the insides.
Abstraction: hiding details behind an interface and leaving a simplified model; "file" abstracts away the sectors on a disk.
Client vs. implementation: the two sides of an interface — the caller is the client, the code that actually does the work behind it is the implementation.
Cache: keeping results you already computed or fetched so the next identical request is free — space traded for time.
Atomic action: one that either completes entirely or appears never to have happened; it never stops half-done.
Log: an append-only record of every state change in order; replay it after a crash and the state comes back.
Throughput: how many requests finish per unit time. "Useful throughput" counts only real work, not time burned on queueing, timeouts and retries.
Overload: demand exceeds capacity, queues grow without bound, and everyone slows down or the system collapses outright.
SOSP: the ACM Symposium on Operating Systems Principles, one of the top venues in systems.

Coordinates

Butler Lampson wrote this at Xerox PARC, where he had a hand in the Alto personal computer, Ethernet, the Bravo WYSIWYG editor, the Dover laser printer, the Grapevine distributed mail and naming service, and the Mesa/Cedar programming environment. He received the Turing Award in 1992. The paper was presented at the 9th SOSP in 1983 and reprinted the following year in the first issue of IEEE Software, which is part of why it travelled so far.

It follows Brooks's tradition of written engineering experience, Parnas on information hiding, and Saltzer's end-to-end argument (both deep-read on this site). What follows it isn't another paper so much as a whole body of engineering common sense passed along by word of mouth.

The problem and the motivation

System design had (and has) an awkward property: there is no computable right answer. You can prove an algorithm's complexity and a protocol's correctness, but real systems rarely fail on algorithms — they fail on judgment: where to cut the interface, what to hide and what to expose, when performance starts to matter, which layer catches errors. Worse is how this knowledge travels: it lives only in the heads of people who have built a few large systems, passed on by apprenticeship and by failed projects. It can't go in a textbook and it can't go in a paper, because it can't be proved — so every generation of engineers repeats the previous one's mistakes.

Lampson's aim was to break that loop. But he understood what kind of knowledge this is, so the form is deliberately modest: not laws, hints — each with a slogan to make it memorable, each backed by real systems on both sides, and each openly admitted to conflict with the others, leaving the judgment to you. That self-limitation is exactly why the paper survived forty years.

Core ideas

Turning design arguments into a 3×3 table

The paper's most underrated contribution is its organizing scheme. Lampson noticed that nearly every design argument lands on two axes: what you're worried about (functionality: is it right? speed: is it fast enough? fault-tolerance: what happens when it breaks?) and where you're deciding (completeness: how much should this do at all? interface: what does it expose? implementation: how do the insides work?). Three by three, nine boxes, and thirty-odd hints each find their place.

Fig. 1 · Three questions by three places: how the paper files its thirty-odd hints. (Cells grouped by theme here, not copied box-for-box from the original table.)

Interfaces: simple, complete, small and fast — pick fewer than three

Lampson frames interface design as a trade-off: a good interface should be simple, complete (nothing essential missing), and admit a small, fast implementation — and satisfying all three at once is essentially impossible, so design is deciding what to give up. Out of that grow a cluster of hints:

"Do one thing at a time, and do it well." "Don't generalize; generalizations are generally wrong." Making an interface general is betting present certainty against future requirements, and when the bet loses, every client pays — in a bloated interface and a slower implementation.
"Use a good idea again rather than generalizing it." Often misread as a contradiction, this is actually the resolution: implement address translation separately in the cache, in virtual memory, and in the file system, each one direct and simple, rather than forcing a "universal mapping subsystem" to serve three different performance requirements. Reuse the idea, not the part.
"Don't hide power." An abstraction's job is to conceal properties you don't want, not to lock away capability you need. If the layer below can prefetch sequentially and the interface won't let you say so, clients simply route around your abstraction — this is the cause of nearly every "our encapsulation got bypassed."
"Leave it to the client," implemented by passing a procedure as an argument. Rather than making the policy decision inside (which page to evict, how to merge a conflict), expose it as a function the caller supplies. Today's callbacks and pluggable policies are descendants of this line.
"Keep basic interfaces stable," and "keep a place to stand." An interface is a contract, and changing it costs far more than changing an implementation; when you truly must, emulate the old interface on the new implementation so existing clients still have a path.

Speed: better fast than general

The most-quoted line here is "Make it fast, rather than general or powerful." Small fast primitives can be composed by clients into whatever they actually need; a large slow feature cannot be decomposed into something fast. Performance is the one property clients can't add from outside — so give less, but give it fast.

The rest is an acceleration toolkit: cache the answers to expensive computations; batch when you can; move work off the critical path into the background; analyze statically instead of at run time; and the wonderfully unacademic "when in doubt, use brute force" — hardware keeps getting cheaper, and a dumb correct algorithm often beats a clever fragile heuristic, besides being easier to debug. "Split resources in a fixed way if in doubt, rather than sharing them" belongs here too: you give up utilization and buy back predictable performance and debuggable failures.

Hints: guesses allowed to be wrong, required to be cheap to check

This is the cleverest line in the paper, and the title's pun. A hint is a guess that may be stale or wrong, but whose correctness can be checked cheaply on the spot; if every hint is wrong the system is still correct, merely slower. That's precisely how it differs from a cache: a cache assumes its contents are valid (hence all the coherence machinery), while a hint assumes nothing — it leaves "being correct" to the authoritative source and only takes the "usually saves a round trip" winnings.

Fig. 2 · How a hint works: guess, check cheaply, take the fast path if right, fall back to the authority if wrong. With every hint wrong the system is still correct, just slow.

The paper's canonical examples are local tables of network addresses and names: the table may be stale, but each use is validated by the response itself. A hit saves a broadcast or a lookup; a miss falls back to the slow path and refreshes the entry on the way. The pattern is everywhere now — branch prediction, optimistic concurrency control, DNS and routing caches are all "verifiable guesses."

Fault tolerance: avoid disaster before you chase the optimum

End-to-end: Lampson's phrasing is stronger than the original — only the application's own checks and recovery are logically necessary; error detection and recovery at any other level is not required for correctness and exists strictly for performance. A lower layer checks errors to avoid retransmission, not to guarantee correctness.
"Log updates" and "make actions atomic or restartable": the truth about state lives in an append-only log you replay after a crash, and every action either leaves no half-finished residue or is harmless to repeat. Together these are the skeleton of database crash recovery (see ARIES on this site) and of all idempotent retry.
"Safety first": when allocating resources, first make sure you avoid disaster rather than attain an optimum — because the optimum usually sits right next to a cliff.
"Shed load": when demand exceeds capacity, actively reject some requests instead of sliding into overload. An overloaded system doesn't just get slower — its useful throughput falls, because queueing, timeouts and retries eat the resources that should have done the work.

Fig. 3 · Why you shed load: past capacity, queueing and retries consume the resources that should be doing work, so useful throughput doesn't plateau — it collapses.

Cutting across the whole table is "handle normal and worst case separately." Their requirements genuinely differ — the normal case must be fast, the worst case need only make progress. Cram both into one code path and you typically end up slow in the common case and shaky in the rare one.

Three lines of ballast

Finally, the maxims that run through everything: "keep it simple"; "get it right — neither abstraction nor simplicity is a substitute for getting it right" (elegant layering cannot rescue semantics that are wrong to begin with); and, quoting Brooks, "plan to throw one away" — the main output of a first system is knowledge, not product.

Key results

It has to be said plainly: this paper has no experiments, no data, no baselines. Its "results" are cases. Lampson argues hint by hint from real systems — Alto, Bravo, Ethernet, Grapevine, Pilot, Star, Mesa and others — with examples where a hint paid off and examples where violating it hurt, and a good share of the negative examples come from systems he worked on himself. The persuasiveness comes not from statistics but from "the witness was there, and is willing to write down his own failures" — which is also exactly where the methodological weakness lies.

Why it matters

Its mode of influence is unusual: it isn't cited into later research so much as memorized and used. "Don't over-engineer it," "leave the decision to the caller," "a hint is allowed to go stale," "shed load," "get it right before you make it fast" — a large share of what's written into company design guidelines and interview questions today starts on this page.

It also became a standard teaching text, and it gave engineers a shared vocabulary: say "that one hides power" in a review and the other person instantly knows what you're worried about. In 2020 Lampson wrote a successor, Hints and Principles for Computer System Design, reorganized into goals / techniques / process with the mnemonics STEADY, AID and ART (AID = approximate, incremental, divide and conquer) — evidence that the list is still evolving.

Limitations and criticism

The evidence is anecdotal, with survivorship bias. The cases come almost entirely from one lab (Xerox PARC), one era, and projects the author was personally part of. We never see the systems that followed the hints and failed anyway — which would be the decisive sample.
The hints conflict, with no rule for arbitrating. "Don't generalize" versus "use a good idea again"; "leave it to the client" versus "keep the interface simple." The paper admits this, but admitting isn't solving: usually only someone already burned knows which applies now, so its practical value to beginners is far smaller than it looks.
Some lines have been rewritten by time. The clearest is "split resources in a fixed way if in doubt." In the cloud, fixed partitioning means paying for idle capacity, and modern practice does the opposite: statistical multiplexing plus automatic quota setting (see Borg and Autopilot on this site — the latter measured that a large share of waste comes from humans setting their requests far too conservatively).
Period-bound omissions. There is essentially nothing on distributed consensus, consistency models, Byzantine failure, or adversarial security — use it to guide a modern distributed system and you'll miss an entire dimension.
The end-to-end phrasing is too hard-edged. "Recovery below the application is only performance optimization" becomes nearly vacuous over a bad link: past some retransmission rate, that "pure optimization" is what decides whether the system is usable at all.
It is unfalsifiable. There's no way to measure whether following these hints actually raises a project's odds. It is closer to an excellent engineer's testimony and teaching material than to a verifiable conclusion — which is precisely why he called them hints rather than rules: the paper is itself a hint. It may be wrong. Please check.

Takeaways

1. In one line: Lampson distilled system-building judgment into about thirty sloganized "hints," organized by a 3×3 table, and said outright that they may be wrong and must be verified.

2. The pain: system design has no computable right answer; failures come from judgment rather than algorithms, and that knowledge lived only in veterans' heads, transmitted by failed projects.

3. The scheme: three questions (functionality / speed / fault-tolerance) by three places (how much to do / interface / implementation) file nearly every design argument into nine boxes.

4. Interfaces: simple, complete, and cheap to implement can't all be had — hence "do one thing well, don't generalize," "don't hide power," "leave the decision to the client," "keep basic interfaces stable."

5. Speed: "fast beats general" — small fast primitives compose, large slow features don't decompose; plus caching, batching, background work, static analysis, and "when in doubt, use brute force."

6. Hints: guesses that may be wrong but are cheap to verify, leaving the system correct (only slower) when they all fail — branch prediction, optimistic concurrency and name caches are all this, and so is the title.

7. Fault tolerance: end-to-end (only application-level recovery is logically necessary), log updates, atomic or restartable actions, safety first, shed load, and separate paths for normal and worst case.

8. Results and influence: no experiments; the argument rests on real systems including the author's own failures — and it spread by being memorized, becoming course material and shared engineering vocabulary.

9. Limits: anecdotal evidence and survivorship bias; hints that conflict with no arbitration rule; lines like "split resources rather than share" rewritten by cloud economics; nothing on consensus or security; unfalsifiable overall.