Dan Luu on bug blindness
Here is the incomparable Dan Luu, arguing that (i) there are way more bugs than most people think and (ii) most of us systematically fail to notice them.
It's a great article; I read its spiritual predecessor, John Regehr's "Operant Conditioning by Software Bugs," over a decade ago, and have thought about it regularly ever since.
Why are people systematically bug-blind? Here are a few of the reasons that come up in Dan's essay (but really, consider just reading it yourself):
- We're very good at adjusting to problems and then forgetting the adjustments. Dan has a wonderful anecdote about how he'd stopped noticing the many physical adjustments he'd learned for his dusty old trackball mouse, which a friend tried and found completely unusable. Many things are like this.
- We are emotionally invested in things we use, and especially in things we make. That causes us to systematically overstate their quality.
- The previous point holds both on a personal level and on an organizational level.
- There are selection effects: people use what they can use, and populations tend to divide into those who can use something well enough to gradually stop noticing bugs and those who abandon using it. (This goes both for products and features.)
I'd add:
- Many bugs are machine-dependent or otherwise setup-dependent, so people tend to see only a subset of bugs. If you use only good hardware, you're likely not only to see fewer bugs but to see less severe versions of bugs. It's a lot easier to ignore race-condition-adjacent bugs, for example, if everything is going faster, if you're on the happy path for authorization, and so on.
- If your ontology is bad, it can be hard even to think about a bug. Let's say your users see a list of hats, and 10% of the listings say that the hat weighs less than a tenth of an ounce. That's bad! If you're repesenting
hatitems reasonably throughout your software, including the front end, you can think: "gee, a bunch of those hat listings are obviously wrong." If, however, your front end sees a bunch ofObjectrepresentations that derive fromIWearableItem | IListableInventoryback-end representations, it's easier to say "oh, yeah, some of thoseListableInventorysources only account for the ink in some of the fields, and ink doesn't weigh much." You might not even get that far, because in the latter scenario it's much harder even to form a complete thought about the issue. This is another reason ontology matters a lot. - For a lot of buggy software, there is a spreadsheet (or bug tracker, test coverage statistic, or whatever else) according to which the software is actually good and not buggy. Even if you routinely laugh at these metrics or roll your eyes at the process of creating them, they have powerful psychological effects, especially collectively.
- There's enormous disparity in how much people use software in the first place, even (perhaps especially) if it's software they work on. Bug-sensitive psyches are not only more likely to notice bugs conditional on encountering them, but to encounter them in the first place. Using the software you make more is an underrated way to be a better programmer.
This is still a much-underrated subject, and I hope more people write about it. (In the meantime: why does MacOS so often falsely claim that touch ID will not unlock my computer and that I need to enter the password? One of the many bug workarounds I've noticed since yesterday is that I often try touch ID no matter what the lock screen says.)