Why Excel

The case for the spreadsheet as production trading infrastructure

Tell an engineer you run a trading desk out of Excel and watch the eyebrow raise. The assumption underneath it is that you must be doing something approximate — a hobbyist's rig, fine for a watchlist, not for real size. I understand the reflex; I once shared it. But the objection runs on out-of-date facts, and the gap between what people assume about Excel and what it can actually carry has become one of the more useful arbitrages I know.

This is the long version of an argument I only gesture at elsewhere: why a spreadsheet — of all things — is the right operating environment for a working trading desk today, and where the real difficulty actually lives. Because it isn't where the skeptics think.

The same thing that happened to Python

Start with an analogy the quant world already accepts. Fifteen years ago you didn't hear much about Python in production finance, even though the language was decades old. The reason was simple: it's interpreted, and for compute-heavy work it could run ten to a hundred times slower than compiled code. That was a deal-breaker — until it wasn't.

The interpreter has gotten faster over the years, and the hardware underneath it faster still. Neither is the real story. The real story is that the hot code stopped running in Python. NumPy is C and Fortran. pandas is C. PyTorch is C++ and CUDA. Polars is Rust. A working quant writes Python at the top and calls compiled libraries underneath, and the interpreter's overhead disappears into a layer the user never has to see. Today Python runs most quantitative R&D — not because it got fast, but because the slow part got hidden behind a legible interface.

The same pattern is available to Excel. It just got less press.

The 2005 objections are gone

The case against Excel for serious work used to rest on three real ceilings: the row limit, the memory limit, and a calculation engine that couldn't use more than one core. In 2005 those were disqualifying. They're also gone. The 2007 release took the grid from sixty-five thousand rows to a million. The 2010 release went 64-bit, so the memory ceiling became the machine's rather than the application's. Multi-threaded recalculation is now a routine assumption. None of this is exotic — it's just old news that the spreadsheet's reputation never caught up with. Run modern Excel on modern hardware and the things that made it a toy for production work twenty years ago simply aren't the constraints anymore.

So the spreadsheet stopped being the bottleneck at roughly the moment Python did. The bottleneck didn't vanish, though. It moved — and I'll come back to where it went, because that's the whole point.

Why a spreadsheet, specifically

Capability is the boring half of the case. The interesting half is why a spreadsheet, as opposed to any other environment that can hold the data.

A workbook is a full-stack application whose source code is legible to the person using it. The data layer and the logic layer aren't hidden behind a compile step and a deployment pipeline — they're right there on the grid. The grid is the UI everyone in finance already knows, whether or not they use Excel itself. And the thing that matters most on a live desk: the person making the decision can change the tool while using it. Another column, a different sort, a new derived field you want under your eye during the close — you don't file a ticket and wait for next sprint's build. Many changes are as quick to make as they are to describe.

There's a developer slogan, usually attributed to Google: Python where we can, C++ where we must. For running a trading operation, my version is Excel where we can — and for the same reason. You reach for the heavier tool only where you genuinely must, and you'll be surprised how far “where we can” extends once the old ceilings are gone. For a trading desk, the spreadsheet is the one screen where every input converges and the decision actually gets made. That isn't a compromise you tolerate. It's the point.

The honest part: the cliff

Here I have to concede something, because the skeptics aren't wrong about everything. Excel's greatest strength — that it makes almost everything look easy — is also the root of its bad reputation. The hard truth is the difference between what can be done and what can be done easily, and Excel is famous for blurring it.

For most of what a desk needs, the easy path and the right path are the same. Then you reach the edge — real-time data, multiple accounts, order entry, all of it staying correct while the market moves and money is on the line — and the ground drops away. The same environment that made the first ninety percent effortless gives you no warning that the last ten is a cliff. People walk off it constantly. They wire a live feed into a few hundred cells, it works fine in a calm market, and then one busy afternoon Excel crashes. Or starts intermittently freezing. Or it looks fine but some prices just silently stop updating. The silent failures can actually be the most dangerous.

So “Excel isn't robust enough for this” is half right. Excel really can't drink directly from a market-data firehose. Recalc has been multi-threaded since 2007, but the path that delivers external data and commits it to cells still runs on Excel's single main thread — the same UI thread that handles COM, VBA, and every other automation callback. An unbuffered feed will overrun it. That's why the obvious bridges fall short: DDE is from 1987 and blocks the UI; ActiveX automation funnels data through that same main-thread apartment and inherits the same bottleneck; VBA websocket scripts block outright while they wait for the network; Python bridges like xlwings route through the same COM apartment and hit the same ceiling. What the spreadsheet needs in front of it is a buffer — something running on its own threads that takes the firehose, regulates the flow, and hands Excel only what it can use on its own schedule. That buffer is where the real engineering lives, and where nearly every attempt comes apart.

Where the bottleneck went

That's the bottleneck that moved. It is no longer “can the spreadsheet hold the data.” It's “can you keep that data correct under load, across dropped connections, without the user ever having to babysit the plumbing.” That problem is genuinely hard. It took me more than half a year and over seventeen thousand lines of C# to solve it properly for the Interactive Brokers TWS API. Those lessons are the subject of an upcoming series of articles.

But it's hard once. Solved properly and tucked behind a clean interface, the difficulty recedes into the background, and what's left is the spreadsheet you already know — now carrying live quotes, positions, account values, and orders with the reliability you'd demand of any production system. That is exactly what StreamXLS is: the integration done right, so you don't have to think about the cliff; you get to keep working where you've always worked.

Excel where we can. For a working trading desk, “where we can” reaches a great deal further than the raised eyebrow assumes — provided the one genuinely hard part is handled by someone who has already gone over the cliff and come back with the map.