Backseat Software

Summary

What if your car worked like so many apps? You’re driving somewhere important…maybe running a little bit late. A few minutes into the drive, your car pulls over to the side of the road and asks: “How are you enjoying your drive so far?” Annoyed by the interruption, and even more behind schedule, you dismiss the prompt and merge back into traffic. A minute later it does it again. “Did you know I have a new feature? Tap here to learn more.” It blocks your speedometer with an overlay tutorial about the turn signal. It highlights the wiper controls and refuses to go away until you demonstrate mastery. Ridiculous, of course. And yet, this is how a lot of modern software behaves. Not because it’s broken, but because we’ve normalized an interruption model that would be unacceptable almost anywhere else. I’ve started to think of this as backseat software: the slow shift from software as a tool you operate to software as a channel that operates on you. Once a product learns it can talk back, it’s remarkably hard to keep it quiet. This post is about how we got here. Not overnight, but slowly. One reasonable step at a time. Software Came on Disks There was a time when software shipped on physical media: floppy disks, CD-ROMs, sometimes even with a spiral-bound manual. Software felt like a product back then. You bought it, installed it, and used it. If you upgraded, it was because you chose to. The software didn’t constantly change underneath you, and it didn’t have the opportunity to ask for your attention beyond whatever UI the developers shipped on day one. That era had real downsides. If you shipped a serious bug, you lived with it until the next release, which could be weeks or months away. If security issues were discovered, your options ranged from “mail a patch” to “good luck.” In hindsight, it’s amazing we survived! But something else was true too. When you were using the software, you were alone with it. As a software developer, if something was wrong, you found out b...