A batch of invoices came in for the reconciliation agent to work through — over 13,000 of them. About 2,000 had no match in our system, and the UI lists those out so someone can follow up. It rendered that list by setting innerHTML with an HTML table holding all 2,000-plus rows at once. A few hundred rows into scrolling, the page was effectively frozen.
I wouldn't have caught this in development. Nobody builds a test fixture with two thousand rows by accident — you build the ten or twenty you need to prove the feature works, and you move on. This is the same shape of thing I've written about before: production has data development never will, and the only way to meet it is to get there.
That's the obvious read, and it's not wrong: dev data is small because it's convenient, not because anyone decided ahead of time it was representative. Scale surprises are the default outcome of building against a dataset that fits comfortably in your head. Fine. Known problem, known fix — get to production sooner, with less at stake, and let reality tell you what you actually needed to handle.
Here's the part that actually stopped me. Suppose a developer had thought to ask, up front: how big does this list actually get? That's the responsible move — the thing code review checklists tell you to do. But think about who answers that question, and how. It's someone on the team who's seen a lot of these lists go by, and their honest answer is going to come from memory, not from a query against real data. "Oh, usually just a handful" sounds like an answer. It's a guess wearing the clothes of an answer, and once it's said out loud by someone who sounds like they'd know, nobody checks it. It gets treated as a fact and built into the design.
That's worse than nobody asking, not better — because "nobody asked" at least leaves the gap visible. A confident, wrong number closes it, and it stays closed until production forces it back open.
The UI fix was straightforward once the real number existed to design against: virtualize the list instead of rendering every row, add infinite scroll instead of one giant table, and show how many rows are actually loaded so it's visibly working instead of silently stuck. None of that is exotic. It's the standard answer to "a list got bigger than expected." The point isn't that the fix was hard. It's that no amount of asking the right question in a planning meeting would have produced this fix, because the number that would have justified it didn't exist as a known fact anywhere in the building until 13,000 real invoices arrived and proved it.
That's the actual case for getting to production sooner rather than later — not just that dev data is small, but that the alternative to "find out in production" isn't "find out accurately in advance." It's "get told something that sounds like the answer, by someone who doesn't know either, and build for that instead."
Field Mappings