Mobile Doesn’t Suck: The Web Made Us Lazy

01/17/2014

I recently read Tim Bray’s Software in 2014, a sort of “state-of-the-industry” post, including what to watch for in the upcoming year.

It was a good read, but I found one of his observations, on the mobile space, interesting:

The update cycles are slow. Days in the case of iOS, hours for Android (compared to seconds for browser-based apps). What’s worse is that you can’t even count on people accepting the mobile-app updates you send them. Got a critical data-losing account-compromising privacy-infringing bug? Sucks to be you.

I LOL’d when I read this. Literally.

Now Tim Bray has been around the block a few times, so I find it interesting that he calls this out as a specific reason why “mobile sucks”¹.

It’s easy to understand why it’s cast as a negative: software deployment directly via the Web has allowed us to reduce update cycles to seconds, be able to “ship the software” multiple times a day, and it removed any input or control users had into that process. It’s also deemphasized any QA process or input since, as Tim notes, have a data-loss or privacy bug? No worries! Deploy the site again!²

The interesting subtext about all of this is that the Web also largely removed direct customer input from the process: back in the bad³ old days, companies usually had two⁴ lines of development: one for sustaining/bug fixes and one for new features. This allowed customers who were happy with the product to get the fixes they wanted, but maintain the stability and product-knowledge they’d come to rely on. Enter the web, and everyone from sales to product management blurred the lines so much as to erase them. Now customers had to take new features (and, as Bray puts it, “sucks to be you” if you were comfortable and productive with the feature set you had!) along with the bug fixes; they couldn’t make decisions about what was best for them. (Interestingly enough, this model started to seep into shipped software as well, cf. web browsers.)

The real ElephantInTheRoom.apk⁵ is that mobile puts some control back in users’ hands. Bray seems to cast the inability to force-feed users your mobile update as a negative, and that Apple and Android are at least partially at fault for constraining how companies shove their untested, poorly-written, and ill-conceived apps down their users’ throats constantly⁶.

And yet, the “data” tells us most customers don’t want new features shoved down their throat. It’s always been unclear to me from a business or product management perspective why this view persists. The upshot seems to be “it ‘sucks’ that the power to control what software users are running is returning to the hands of the users.”

I for one don’t see this as a negative.

Of course, in Bray’s hypothetical, it really would “suck to be you” if you had a data-loss or privacy-violating bug. But the hypothetical totally avoids the question of “How did those problems come to be?”. It optimizes away⁷ the bit about the Web has facilitated the industry ignoring the quality aspect of the software they ship, because the distribution levers were entirely within their control.

In effect, the Web made us lazy. And it’s not that “mobile sucks” because it doesn’t follow this model. Mobile is the pendulum swinging back ever-so-slightly to the way software had been shipped since its inception, and empowering users to make their own decisions. It’s also putting the onus on us as an industry, again, to care about quality, and do a bit of, y’know, actual planning and thought, before we push the “Publish to the App Store” button. Because mashing the hell out of that button isn’t an option anymore.

The mobile development explosion is introducing an entire generation of engineers who grew up with the Web to the fact that the world isn’t just the Web, and the problems involved with deploying and shipping “packaged” software never actually went away.

Apparently, it’s reminding industry veterans of that fact as well.