The counterweight, quoted carefully

A dissection that only praises its subject is advertising. Two things are wrong with the grid, and one of them is the reason the rewrite gets funded in the first place.

The first is errors. The best source is a peer-reviewed critical review by Stephen Powell, Kenneth Baker and Barry Lawson of Dartmouth's Tuck School of Business (Decision Support Systems, 2008). Across the seven most recent field audits they reproduce, covering 88 operational spreadsheets, 94% contained at least one error, and the weighted average cell error rate over the 43 sheets with cell-level data was 5.2%. That pair of numbers is the most-quoted statistic in the field, and it must never travel without the three objections its own source raises: three of the seven sources are unpublished; most gave "little or no information on their definition of errors or on the methods used to find errors"; and the single source accounting for 70% of the cell-error sample did not report a cell error rate at all. The same authors record that no accepted taxonomy of spreadsheet errors exists and that "essentially no research has been conducted on the impact of errors in spreadsheets." So the direction is well supported and the magnitude is not, and every circulating dollar figure for what spreadsheet errors cost traces to press reports rather than to audited measurement. This piece therefore quotes no such figure.

There is a dissent, and it is awkward, because it comes from the paper this article leans on hardest later. Powell and colleagues record that the one study concluding errors are not a problem is Bonnie Nardi and James Miller's, whose interviewees "routinely track down errors before they can do any real harm" — and they discount it on method, because that conclusion rests on what developers said about themselves rather than on an audit of their sheets. Both halves belong on the record.

The second defect is structural, and the same ICFP paper quoted above names it: spreadsheets "lack the most fundamental mechanism that we use to control complexity: the ability to define re-usable abstractions." Everything the grid does well, it does by having no abstraction barrier. That is not a bug somebody can patch out; it is the same property, read from the other side.

The catalog that collapsed

There is a way to check whether a rule like this is real, and it is not argument. It is counting how much work it deletes.

Every spreadsheet has a reference-transformation catalog: the table of what each form of reference does under each structural edit. Four notations — A1, $A1, A$1, $A$1 — under copy, fill, move, insert, delete and sort, plus what a deleted target does. That is where spreadsheet defects live, and the implementation plan for the workbook described here named it as the single largest risk in the project. Tedious rather than hard, and the tedium is what decides correctness.

Building it produced one row.

Sorting, reordering, moving, inserting and deleting appear nowhere in the finished code, because there is nothing for them to do: the reference names a subject, and none of those edits change which subject it is. Copy is the only survivor, because a copy means "the same shape somewhere else," and shape is a claim about coordinates rather than about identities. So the function that shifts a reference exists for exactly one caller, and the deleted-target row became a typed refusal rather than a rewrite.

The budgeted tedium was tedium the decision had already eliminated. That is the strongest evidence available that identity-over-position is load-bearing rather than tasteful: it did not make the catalog easier to write, it made most of the catalog not exist.

It happened a second time, one level up. A workbook has several sheets, and the obvious model gives each one its own coordinate space, with cross-sheet references as a separate mechanism spanning them — a reference that carries a sheet and a coordinate. Look closely and that is the original mistake wearing a different hat: the pair names a cell only relative to a grouping, and a grouping is exactly the sort of thing a reorganization changes.

So a sheet is a grouping over cells, not a space of its own, and identities are unique across the whole workbook. A reference already names one cell without saying which sheet holds it. Cross-sheet references then need no mechanism at all: the evaluator cannot tell that a boundary was crossed, because there is nothing in the reference that records one. `Ledger!A1` is a lens, exactly like `A1` — it says whose coordinates to read, and then it is gone.

Two things fall out that are worth more than the implementation convenience. Renaming a sheet touches no formula, because the name was never in the formula. And the same formula reads Ledger!A1 from one sheet and A1 from another, because "foreign" is a fact about where the reader is standing, not about the reference.

The dollar sign is an instruction

If copy is the one edit that acts on coordinates, then the author needs exactly one lever over it, and every spreadsheet already ships that lever: the $. Under the identity model its meaning becomes precise. A1 in a copied formula says "translate me — keep my shape relative to where the formula lands." $A$1 says "do not translate me." The dollar sign is not decoration on an address; it is a per-axis instruction to the single surviving coordinate transformation.

That precision forces a storage decision that is easy to get wrong, and this workbook got it wrong first. A dependency held (subject, lens) and nothing else — which reference the author wrote, A1 or $A$1, was not recorded, because for every operation except copy the two are indistinguishable. The formula evaluated identically. The sort survived identically. The defect surfaced only at the third hop: commit a formula, copy it, and a reference the author had pinned moved anyway, because the pin existed only in the editor's draft and the draft was gone. The repair widened the stored dependency to carry two anchor flags per axis — for a range, per corner of its normalized rectangle — so the instruction survives the trip through storage, through the wire bytes, and back out to the copy that finally consumes it.

The general lesson is worth lifting out of the spreadsheet. When one operation in a system consumes an attribute that every other operation ignores, that attribute will tend to fall out of the model, and its loss is invisible until the one consumer runs. The test that catches it is a round trip through the layer that forgot: write $A$1, commit, read the formula back. A sheet that answers A1 has discarded an instruction while preserving every value.

Positions are not operations

Here is where the same rule shows up again, one level down, and where building it taught me something the design document had not said out loud.

Two people editing one sheet is the normal case rather than the advanced one, and that has been the measured position since 1991. Bonnie Nardi and James Miller interviewed spreadsheet users at Hewlett-Packard Laboratories and reported, in their own emphasis, that "spreadsheet co-development is the rule, not the exception" (International Journal of Man-Machine Studies, 1991). Their explanation is a claim about the grid's shape: "the division of the spreadsheet into two distinct programming layers permits effective distribution of computational tasks across users with different levels of programming skill." One person owns the domain and the numbers, another writes the formulas, and the grid is what lets them divide the work without a meeting. A rewrite that ships a single-writer form has not merely dropped a feature; it has dissolved that division of labor.

Second on their list of observed cooperative activities: users "transfer domain knowledge via spreadsheet templates and the direct editing of spreadsheets." Nobody needs to be persuaded that a template can carry expertise. People have been doing it for thirty-five years, informally, with nothing checking the transfer.

Two people are looking at the same sheet. Both insert a row after row three. Each sends the other "insert at position four."

Apply mine, then theirs: my row lands at four, theirs lands at four and pushes mine down. Apply theirs, then mine: the mirror image. Same two edits, two different sheets. The operations do not commute, so the two people now disagree about what the document says, and no amount of careful merging afterwards recovers the intent — the information was lost when the edit was described as a position.

The fix is the same rule as before. An insertion must carry a stable key for where it goes, computed once against the state its author actually saw, rather than an index interpreted against whatever state it happens to arrive at. Give positions dense fractional keys — keys with the property that there is always room for another key strictly between any two — and insertion becomes commutative. Both rows survive, both people see the same order, and nobody had to be the server.

That is not a collaboration feature bolted onto a grid. It is the same sentence as before: identity, not position, applied to operations instead of to references.

There is a wrinkle worth knowing about, because it is easy to miss until something is actually built. Two people inserting into the same gap, each looking only at the neighbours they can see, compute the same key — the key is a function of those neighbours, and they agree about them. So keys alone leave a tie, and a tie is an ambiguity about order. The repair is small: order by the key first and by the participant's own stable identity second. Identity does the work twice, once to say where and once to break the tie.

Two workbooks, one document

The demonstration above is a model of the problem. Here is the mechanism itself, running, on a network that is trying to break it. The two grids below are both real workbooks — the same component as the figure at the top of the piece — over one document, joined by a simulated wire. You are both participants: type in either grid and the edit lands there immediately, joins that seat's pending run, and crosses the strip drawn under the grids. The colored outline with a name on it is the other participant's cursor, in that participant's own color; your own cursor keeps the ordinary accent in both grids.

You control the wire. The selector offers three of them. Fast delivers in 150–450 milliseconds and loses nothing. Lossy, the one the figure opens on, delivers in 150–1200 milliseconds and loses one delivery attempt in five. Hostile takes 300–2400 milliseconds and loses nearly half. Every delay and every loss is drawn from the seed beside the selector, so a run is reproducible: the same seed replays the same schedule, mark for mark, and "New schedule" moves to the next one. Nothing in the figure calls the platform's clock or its random number generator directly; both are capabilities the demonstration is handed, which is also how the tests replay a failing schedule.

Watch the strip rather than the sheets for a moment. Each mark is one delivery attempt, travelling in its sender's color, from that sender's end toward the other. Because every attempt draws its own delay, two marks can cross: the second edit you made can arrive first. A mark that draws a loss stops where it failed and stays there as a small ×, and a resend re-enters from the sending end as a diamond rather than a dot — so a repair is legible as a repair. The counter under each name reads in flight, dropped, redelivered, and the indicator on the control strip says converged only when both sheets, compared cell by cell, actually agree.

Losing an operation would be a broken workbook, not a chaotic one, so the wire repairs what it drops. The repair is deliberately the simplest correct one: each seat keeps re-offering whatever is still pending until an exchange lands. A seat's pending run is its unacknowledged set — the exchange clears it exactly when it lands — so the repair needs no acknowledgment channel and no sequence numbers, and a resend that arrives after the exchange already landed changes nothing, because an exchange with nothing pending is a no-op. That last property is what makes reordering harmless at the transport layer, and it is the same idempotence the merge relies on above it.

Now the sheets. Edit both grids before either delivery lands — easy on Hostile — and the two runs are genuinely concurrent, exactly the situation that made position-carrying operations disagree. Nothing here carries a position. Each operation names the row and column subjects it touches, the merge puts both runs in one canonical order — the kind of operation, then the identity it names, then the participant — and both replicas compute that order independently and agree. That order is a property of the operations, not of the wire: it is computed from what each operation names, so no schedule of delays, drops, and resends can reach it. Arrival decides nothing, which you can now check by being genuinely unfair rather than politely so.

The same identity rule is why a structural edit on one side cannot corrupt the other side's work. Delete a row in one grid while typing into a different row in the other: the deletion names the removed row's subject and the write names its own, so the merge has no coordinates to confuse, in the same way the earlier sort had no references to retarget. And when the two of you genuinely collide — different values, one cell, one window — the merge does not pretend otherwise. The canonical order picks the same winner on both grids, and the notice line under each reports whose value was kept and whose was set aside, because a lost intent the loser was never shown is how a shared sheet stops being trusted.

And once more, in the renderer

The rule turns up a third time, in the least expected place.

Build the demonstration above as a widget and you will probably render it the obvious way: on every state change, throw away the controls and rebuild them from the current state. It is simple, it is easy to reason about, and it is wrong for a reason that has nothing to do with spreadsheets. Browser focus is attached to a node, not to a position in the markup. Destroy the button somebody is standing on and recreate an identical one in the same place, and their focus does not move with it — it falls back to the top of the document. Everything looks right. A mouse user notices nothing. A keyboard user is thrown to the start of the page every time they answer.

The fix is the sentence again: keep the node's identity and change its properties, rather than replacing it with something that merely looks the same. Three layers — references, operations, DOM nodes — and one rule. That is usually the sign that the rule is real rather than a convention someone chose.

Why the replacement always feels dead

The dependency graph is usually filed under performance. It is really what makes a spreadsheet feel alive, and that is the part the rewrite loses without ever deciding to.

A spreadsheet is reactive by construction. The graph is not a feature somebody scheduled; it is the only way the thing can work at all, so every value in the document is live for free. Change an input and everything downstream is simply correct, including the parts you were not looking at.

Now write the replacement. It has a database and it has forms, and a form is a request: fill it in, submit, wait, re-read. Nothing is downstream of anything, because there is no graph — there are handlers. Liveness in that architecture is a thing you build, one dependency at a time, by hand, and each one is somebody's ticket. So it doesn't get built. Not because anyone chose a dead interface, but because reactivity stopped being free the moment the graph was replaced by request handling.

That is why the rewrite so reliably feels worse in a way its authors find hard to name. The spreadsheet's recalculation was its interactivity. Throw away the dependency graph and you have not merely made it slower to update — you have made liveness a budget item.

One keystroke, three meanings

The part of a spreadsheet that feels most like muscle memory — type =B2*, press an arrow, watch a reference appear — is a small machine with a sharp rule, and writing it down is what makes the behavior specifiable rather than folklore. While a cell is being edited, an arrow key means one of three things, and the mode decides which:

The rule that keeps this honest: point is derived, not remembered. The editor does not carry a flag saying "we are pointing now." It looks at the draft and the caret — is the character before the caret one a reference could legally follow? — and the mode falls out. A remembered flag drifts from the text it describes; a derived one cannot. Edit is the single sticky mode, because F4's cousin F2 is a deliberate statement that the arrows belong to the text, and a deliberate statement should not evaporate on the next keystroke.

Point mode also explains why the sheet outlines cells while a formula is half-typed. The reference under construction is a pair of subjects — an anchor and a moving head — held exactly the way the selection holds its cells, and the outline is that pair projected back onto the grid. The text =A2:A4 growing in the draft and the dashed rectangle growing on the sheet are two renderings of one value, which is why they cannot disagree.

One more small surface carries a load-bearing distinction: the formula bar shows a computed cell's source while the grid shows its result. Those are two honest readings of one stored value, and a sheet that shows only the result has made the formula unreachable — the reader can see 20 and has no path back to the =B2*C2 that produced it, which is how an accidental keystroke erases work nobody was shown.

If a workbook has a real semantic core, then a table, a data grid, an admin index, and a lightweight sheet are all the same thing with different capabilities switched off. An application can embed a workbook view bounded to the columns and the editing policy it needs, and the people using it keep the interactivity and the collaboration they had. The engineering team gets its schema and its scale. Nobody keeps a second spreadsheet on the side, because nothing was taken away.

The obvious objection is that you cannot always embed. Some data belongs to a system you do not own, and the sheet has to meet it somewhere. The tempting answer is to synchronize the two — and it is the wrong one, because a sync loop does not remove the second source of truth. It automates the reconciliation nobody owned, and turns visible disagreement into silent drift.

The honest shape at a boundary you cannot dissolve is a projection with a direction. The workbook reads the other system as a bounded, dated observation rather than as a peer to be merged with, and writing back is a proposal against the owning system that may be refused. Refusal is the load-bearing part. An adapter obliged to produce a write will always produce one, including when the other schema cannot represent what the sheet meant — so an adapter that cannot refuse is not an integration, it is a divergence generator with good manners.

That is the actual claim: the spreadsheet keeps winning because it is the requirement, and the way to stop losing to it is to stop trying to replace it.

The incumbent answered the abstraction problem the other way

The counterweight earlier named the grid's structural defect on Peyton Jones, Blackwell and Burnett's authority: no reusable abstractions. On 2021-01-25 Microsoft Research announced its answer. The LAMBDA worksheet function, authored by Andy Gordon and the same Simon Peyton Jones, lets an author name a function in the formula language and call it, including recursively. The announcement does not hedge: "With LAMBDA, Excel has become Turing-complete. You can now, in principle, write any computation in the Excel formula language" (Microsoft Research Blog).

That runs against the direction this piece has been building toward. A sheet that is also an embeddable component with rules attached wants those rules to be decidable: a template installed from a stranger should be answerable in advance about what it can refuse and what judging one edit costs, and neither question has an answer over a language in which a guard may fail to terminate. So the honest position is that the dominant vendor, advised by one of the researchers whose diagnosis this piece adopts, made the opposite call and published it as progress. A constrained rule language is a position to be argued rather than the obvious default.

The distinction that survives the concession is narrow, and it is worth having exactly because it is narrow. LAMBDA extends the formula language, whose author writes it, runs it in their own session, and bears its costs personally. A template's rules are received: somebody else's grammar judges your edits, on your data, on every keystroke. Expressiveness serves an author; decidability serves a reader. No study tests whether that distinction holds up in practice, and this piece does not claim one does.

Feasibility was settled twenty years ago, and nobody adopted it

Martin Erwig's group at Oregon State University built the constrained-template idea two decades before this article. Gencel supplies a template language, a table calculus, and a type system (Journal of Functional Programming, 2006); ClassSheets supplies an object-oriented template notation from which a spreadsheet application is generated (ASE 2005). The project's own claim is stronger than anything argued above: a user may modify a generated sheet "only in the anticipated ways, so that spreadsheets evolving from templates will provably never contain any reference, range, or type errors" (the Gencel project page).

The line is intellectually mature and commercially invisible, and that reorders the problem this article is really facing. The open question is not whether a constrained grid can be built correctly — that was answered, with proofs, in 2006. It is whether a domain expert will accept the constraint. No evidence of production adoption for those systems was located, and no survey of what became of them was located either — which is an absence of a positive finding rather than a measured failure, and the difference matters. One claim must not be made in either direction: Gencel's guarantee is a type-system guarantee about three error classes in generated sheets, and no research establishes that a template reduces the errors real people make on real tasks.

A quarter of the shadow systems had no expressiveness excuse

The argument above rests on misfit — the sheet exists because the application cannot express the work. One study inventoried 99 shadow systems across three organizations and classified each by whether the enterprise system already held its data and could already do its job (Systems, 2016). Inside their grey zone the authors report a one-directional finding that supports the argument: they found sheets whose data the enterprise system already held and whose function it could not provide, and no instances of the reverse.

Then the number that does not support it. Twenty-seven of the 99 were fully dependent: the enterprise system could provide every function of the shadow system and already held its data. For roughly a quarter of the instances the application could express the work, and somebody built the sheet anyway. Access, permission, latency, habit, and not knowing what the application already does are the remaining pool of explanations, and no source separates them. A product that fixes only expressiveness leaves that quarter exactly where it found it.

Somebody already paid to put the grid beside the application

The strongest market evidence for the demand this article describes is also a caution about the remedy. Salesforce acquired Quip — a product combining documents, spreadsheets, task lists and team chat — in August 2016, announcing consideration of approximately $582 million in stock and recording $412.0 million, of which $357.6 million was goodwill. It then spent years wiring live, writable CRM records into those documents. Companies do not pay that for something their users do not want.

Salesforce is now retiring it. Its own help documentation states that new paid, free and trial Quip accounts stopped being available on 2026-02-17, and that "Quip End of Renewal will be effective March 1, 2027", with the use cases directed to Slack and Agentforce Sales (Salesforce Help). Salesforce never disclosed a Quip revenue, seat or customer figure, and recorded only that Quip revenue was "not significant" in fiscal 2019 and 2020. The shape repeats elsewhere: Google built the structured grid as Tables, and its own support page says "the product was turned down on December 16, 2025" (Tables Help Center); Airtable and Rows both sold a spreadsheet-shaped pitch and both dropped that framing on the way up-market.

Three disciplines apply to those two paragraphs, and they are why the paragraphs sit here rather than in the argument.

First, Salesforce did not grow as a grid. The word "spreadsheet" appears zero times in its 2003 Form S-1 and zero times in its FY2008 Form 10-K; the filings credit multi-tenant delivery and, later, a metadata platform. Quip arrives a decade after the growth anyone would need it to explain.

Second, Salesforce has a formula language, and any claim that it does not is false. Its own training material compares writing one to "creating a formula in a spreadsheet cell". The defensible statement is about shape: a formula field is declared once per field on an object, is scoped to the record and its relations, and is read-only — "these fields are defined by a formula, which is an algorithm that derives its value from other fields, expressions, or values" (Salesforce object reference). That there is no user-authored cell-to-cell dependency graph follows from those documented semantics — it is an inference from what the documentation describes, not a denial the documentation makes, and it is marked as an inference here for that reason.

Third, and most uncomfortably: none of this is evidence that the answer in this article works. "A grid beside the schema was retired, therefore a grid that is the schema succeeds" is a non-sequitur. Quip's end state removes one rival explanation and supplies no support for the alternative, because nobody has shipped the alternative at commercial scale. The shadow-systems literature's own usual remedy runs the other way as well: absorb the shadow system into the system of record, or govern it where it stands — rather than hand the domain expert authority over the application's shape. That literature diagnoses the disease this piece is treating and prescribes a different medicine.

What survives all three is one modest sentence, and this piece claims nothing past it: people keep the grid beside the application, four research communities have documented that for forty years, and a mature vendor paid heavily to bring the grid inside and is walking it back out.