1000 is Not A Big Number: The Fallacy of Small Numbers
Too often I hear developers insist that they can’t do something because it’s “too hard,” and what they mean is not that it requires hundreds of A100 GPUs and petabytes of RAM or that it’s equivalent to solving the halting problem. It means they’re going to have sit at their laptops and work on (or prompt LLMs to work on) a few dozen small, individual tasks.
One common area where this comes up is bug triage. “Of course, we can’t look at all the bugs in the bug tracker and prioritize, respond, to and fix all of them. There are too many!” Really? How do you think the bugs got there? Mostly by individual people typing the details in one-by-one. If individual people created the bugs, then the number of bugs is by no means too large for individual people to respond to. A few years ago I read and responded to every old issue in the Apache Maven project Jira over Christmas break. Me. One developer working in my spare time over a few weeks. Probably over a thousand bugs. It isn’t actually that hard to do. You just need to do it.
Another failure of reasoning about small numbers comes up in special cases. Multiple times I’ve been told something like, “We can’t write special code for each of these products. There are too many of them,” when “too many” means 100 to 200. That is not a large number. You totally can write special case code for under 200 special cases. It’s even easier when the top 10 or so special cases account for 99% of what happens in practice. And when solving one special case is better than solving no special cases. A variant of this fallacy is the claim that “We can’t possibly fix all the problems with one-off solutions” as if that implies that you can’t or shouldn’t fix the one or two problems that are causing 90% of user pain. The perfect should not be the enemy of the good. When there’s no perfect solution, pick the better one.
At various times in my career I’ve been called in to fix some problem that comes up in production in an enterprise facing service, and I’ve looked at the issue and said, “Let’s call them up on the phone and politely ask those three customers to stop doing that,” or “Let’s help these 12 customers migrate onto the product we want to support.” Too often, the answer is “That’s too hard. We can’t talk to all the customers.” Really? You can’t talk to 12 people? You’d rather burn months of SWE-time to support an underused service with 12 users?
Not every problem requires a scalable or general solution. Instead of building massive systems that require big design docs, multiple layers of approval, 100 person development teams, and years to launch, sometimes the right answer is to build 200 small systems that each handle one problem for one customer. You can do a hell of a lot with a single if–else block that dispatches to a few dozen to a few thousand special purpose methods and classes. Use a runtime configurable lookup table if you’re feeling cocky, though honestly that’s over-engineered for most problems.
Anytime you have a list of special cases, or even special cases that roll in one at a time over years, just fix the special cases one by one. If there is a general solution and it’s cheap, implement it. Often that’s the right way to go. But if there is no general solution, don’t let the lack of one prevent you from solving the problem. Stop being scared by small numbers. Roll up your sleeves and get to work.
