Thursday, January 22, 2026

Backseat Software

Mike Swanson (via Brent Simmons):

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.

[…]

And that’s when the vocabulary starts to creep in. DAU. MAU. Retention. Funnels. Stickiness. Cohorts. Conversion. Gamification. Oh my!

If you’ve worked inside a modern product organization, you’ve heard these words so often they start to feel unavoidable.

[…]

The analytics didn’t prove the feature was unwanted. The analytics proved that we buried it.

Previously:

Update (2026-01-30): See also: Hacker News and John Gruber.

4 Comments RSS · Twitter · Mastodon


Software and websites equally are hell to use because of the constant, constant, constant interruptions, regardless of how many times you use the software or visit the site. If I tracked every incident where I speak derogatively to a machine, I bet 90% of these incidents are me trying to do something quickly and getting interrupted by something I couldn’t care less about.


I looks like Brent assumes companies want to write good software. Similarly to users, who don't want a drill but a hole in the wall (or rather a hanged picture), companies don't care about the software or its users but just want to earn money. Enshittified software earns more money. Maybe not over 10 or 20 years but who knows if it would survive a year, let alone 10+ years?


Nope, no defence of telemetry, *unless* the user is asked explicitly to volunteer information which they can review and understand before sending it to you. Crash reports, usage reports, whatever—it's all signal that biases outcomes to the primary benefit of profit-seeking. Just say no. Instead, form strong relationships with your customers and encourage them to tell you what's on their minds. Request crash reports on an individual basis. And notify them of features using external channels (like email).

As the article said, it's the always-on connection (as opposed to, say, a dial-up one) that allowed developers to recruit their paying customers as data gatherers and lab rats. But that's all. Developers simply took advantage of that power to the users' detriment. So right conclusion, wrong rationale.


During my 25 years in web I have helped many marketing departments set up analytics and A/B tests. Never seen any real benefits from it. Could be because the data was handled by lazy people, I don't know.

What I do know is that they always need a few more datat points and then they will solve whatever it is.

Leave a Comment