IEEE Standard for Floating-Point Arithmetic (IEEE 754)
The forty-year-old standard that governs every floating-point calculation your hardware will ever perform. The reason 0.1 + 0.2 gives the same wrong answer on every machine on Earth.
Reference / cited works 17 resources
the resources.
Every book, paper, standard, and idea mentioned across the writing — with a note on why each one is here.
How a citation reads inline
The idea comes from IEEE Standard for Floating-Point Arithmetic (IEEE 754)[01], and the numeral takes you to the full entry at the foot of the essay.
Science
3 resourcesPatriot Missile Defense: Software Problem Led to System Failure (IMTEC-92-26)
The official documentation of the Patriot missile system failure in Dhahran. A floating-point accumulation error in the system clock, compounding over 100 hours of operation, caused a 0.34-second timing gap — enough to miss a Scud.
Appears in ×1
The generalization of 'Student's' problem when several different population variances are involved
The correction the sidenote leans on. Student's t-test assumes the two groups share a spread; Welch drops that assumption and pays for it with fractional degrees of freedom, computed from the two variances rather than counted from the two sample sizes. It is the honest default whenever two samples are small and there is no reason to believe their scatter is identical — two quarters of a team's sprints, for instance.
Appears in ×1
Software
14 resourcesThe Mythical Man Month
The tar pit of software complexity — all sufficiently complex systems have hidden parts far larger than visible ones. Adding people to a late project makes it later. Still the clearest book about why software is hard.
Appears in ×1
The Craftsman
The philosophical case for craft: doing something well for its own sake. What distinguishes a good craftsman from a long-tenured engineer is not time served but attitude toward the work.
Appears in ×1
Linearizability: A Correctness Condition for Concurrent Objects
The paper that defined the word, and the reason the definition is about a single object. Correctness here is a property of one object's history: every operation looks as though it took effect at an instant between its call and its return, and those instants respect real time. Read it once and the confusion with serializability stops being possible — that one is about many objects and no clock.
Appears in ×1
The serializability of concurrent database updates
The other half of the pair, from the database side and eleven years earlier. Serializability asks only that the outcome match *some* serial order of the transactions — which order is not specified and does not have to be the real-time one. That "some" is the whole difference, and it is why strict serializability needs a separate name.
Appears in ×1
Time, Clocks, and the Ordering of Events in a Distributed System
Where happens-before comes from. The argument is that a distributed system has no global clock to appeal to, so the only ordering you can actually establish is the partial one causality gives you: within a process, across a send and its receive, and transitively. Everything in the causal-consistency row of the table is downstream of this eight-page paper.
Appears in ×1
Session guarantees for weakly consistent replicated data
The four session guarantees, named and separated: read-your-writes, monotonic reads, monotonic writes, writes-follow-reads. This is the paper behind rank 5.5 and behind the claim that most requests for "strong consistency" are really requests for one of these. They are granted per session, which is why they cost a version vector and a sticky route rather than a consensus round.
Appears in ×1
Conflict-free Replicated Data Types
Where associativity, commutativity and idempotence stop being three separate algebra words and become one engineering result. Make the merge a join on a semilattice and replicas converge without coordination — no leader, no quorum, no rollback. The essay says the semilattice guarantees convergence but not when; this is the paper that proves the first half and is honest about the second.
Appears in ×1
Keeping CALM: When Distributed Consistency is Easy
The CALM theorem, stated as an if-and-only-if: a program has a coordination-free distributed implementation exactly when its logic is monotonic. What makes it worth reading rather than quoting is the direction people skip — non-monotonicity is not a hint that coordination might help, it is a proof that you cannot avoid it.
Appears in ×1
The Byzantine Generals Problem
Where the 3f + 1 bound comes from, and why it has that shape. The fault being modelled is not a node that stops but a node that lies, differently, to different neighbours — which is why three nodes cannot survive one traitor: the two honest ones cannot tell which of the other two is lying. Reach for this only when the failure really is malicious; ordinary crashes are a cheaper problem.
Appears in ×1
Spanner: Google’s Globally Distributed Database
The TrueTime entry in the table, in its own words. Spanner does not defeat the clock problem, it bounds and then publishes it: TrueTime returns an interval rather than an instant, and a commit waits out the uncertainty window. That is the honest price of real-time ordering at global scale, and it is paid in latency.
Appears in ×1
How to do distributed locking
The clearest statement of why a lease is only half the story. The diagram to remember: a client pauses for GC, its lease expires, it wakes up believing it still holds the lock, and writes. No lock service can prevent this from its own side — only a monotonically increasing fencing token checked at the storage layer can.
Appears in ×1
Gray Failure: The Achilles’ Heel of Cloud-Scale Systems
Names the gap this failure mode lives in: the system observes its own health differently from the way its clients experience it, and gray failure is exactly the region where those two disagree. The useful consequence is that a health check answering for the node rather than for the request is not a detector, and adding more of them does not become one.
Appears in ×1
Static stability using Availability Zones
Static stability written up by the people who had to operate it. The rule it argues for is that the data plane must keep serving on whatever it already knows when the control plane is unavailable — which means pre-provisioning capacity you are not using, and refusing to make recovery depend on anything that has to succeed during the incident.
Appears in ×1
Designing Data-Intensive Applications
The one book to read beside this vocabulary. Chapters 5 and 9 are the long version of the consistency table, and they do the thing a glossary cannot: carry each guarantee through to what it costs in replication, in latency and in what a client is allowed to assume. Where this piece names the confusions, the book works out their consequences.
Appears in ×1
Updated as the writing grows.