"VisiCalc, 1979, and the Problem It Created"

VisiCalc shipped for the Apple II in October 1979. Dan Bricklin, then a student at Harvard Business School, had built a prototype the year before because he wanted to run what-if projections without booking time on a mainframe or waiting for the campus computing center. His co-creator Bob Frankston turned the prototype into a product, and Personal Software published it for $100.

Within two years the software was selling 12,000 copies a month. Over the next six years it moved more than 700,000 units, and the common line in the industry press was that people were buying Apple IIs specifically to run VisiCalc. The spreadsheet didn't just find a market. It created one.

What the spreadsheet replaced

Before VisiCalc, getting a set of projections meant one of two things. Either you did the arithmetic by hand on a paper ledger, erasing and recalculating every time an assumption changed, or you submitted a job to the computing department and waited for the printout. Both paths ran through a bottleneck. The paper ledger was slow. The computing center was gatekept.

What nobody said out loud was that the bottleneck was doing two jobs. It was slowing things down, which was the visible problem, and it was concentrating definitions in one place, which was the invisible benefit. When the numbers came from accounting, everyone looked at the same numbers. Not because the company had a governance policy. Because there was only one set.

Bricklin's invention removed the bottleneck, and the control left with it.

The pattern that followed

Once any manager could open a spreadsheet and build a model, every department got its own version of the revenue forecast, its own margin calculation, its own customer count. Each was internally consistent. Each used slightly different definitions, pulled from slightly different source data, at slightly different times. No mechanism for reconciling them arrived alongside the tool.

This was the plan working, not an accident. VisiCalc was designed to put the numbers on the desk of whoever needed them, and it did exactly that. The problem is that "whoever needed them" turned out to be twelve people in eight departments, each building the number their way, and no one of them was wrong.

Lotus 1-2-3 arrived on the IBM PC in January 1983 and accelerated the pattern. By the mid-1980s, large companies routinely had dozens of spreadsheets computing the same metric with different answers, and the monthly management meeting opened with twenty minutes of arguing about whose total was right. Mitch Kapor, who designed Lotus 1-2-3, later said the spreadsheet "gave people the ability to calculate, but the challenge became making sure everybody was working from the same numbers."

The second wave

Self-service BI repeated the pattern in the 2010s. Tools like Tableau and Looker put chart-building on every desk, which solved the "I need a dashboard and IT has a six-week backlog" problem. What they did not put on every desk was a shared definition layer. A marketing director and a finance analyst could both build a revenue chart in the same BI tool, from the same warehouse, and get different totals because one filtered out returns and the other didn't.

Gartner's 2017 survey on data and analytics governance found that organizations with shared metrics outperformed their peers, but the harder finding was buried in the methodology: most organizations couldn't say whether their definitions were shared, because no one had written them down in a place a second person could find.

The bottleneck moved from computing to visualization, and the control, the implicit agreement on what a number means, left again.

The third wave

The modern cloud warehouse made every source queryable by anyone with SQL access. Redshift, BigQuery, Snowflake, Databricks. The analysis bottleneck dissolved further. An analyst who once waited for a data engineer to build a table can now query the raw event stream directly.

The semantics are still somebody else's job. Or more accurately, they are nobody's job. The warehouse holds the data. It does not hold the agreement about what the data means. Two analysts querying the same table with slightly different WHERE clauses will produce two defensible answers to the same question, and neither will know the other exists until a VP gets two slides with different numbers in a quarterly review.

Every wave has also produced a tool meant to fix the problem. Lotus added shared workbooks. BI platforms added governed data sources. The modern stack has semantic layers and metric stores. Each treats the gap as a tooling problem. It isn't. It's a coordination problem. The tool can enforce a definition, but someone has to write it first, and that requires the three people who each have their own version to sit in a room and pick one.

What the pattern predicts

Each wave removed a bottleneck that was partly a bottleneck and partly a control. Each delivered on speed. None replaced what the removed layer had been doing quietly.

The current wave, LLMs and AI-assisted analytics, is on the same trajectory. A tool that writes SQL from a natural-language question removes the analyst as bottleneck, which is the visible problem it solves. What it does not do is establish which of the four revenue definitions in the warehouse is the one the question is about. If three analysts would have written three different queries, the model will write a fourth.

When a tool makes it cheaper to produce an answer, the scarce thing becomes agreement about which answer counts. That has held through three of these transitions now. The tools keep getting faster. The coordination problem keeps being the same size.