Autoupdate hell I should say as preamble to this piece that I hate being in the car. I do 30,000 miles a year, and half of that is on the most congested road in the UK. To be frank, it’s soul-destroying.
Which is why when I go to a car dealership to swap out one car for another I’m very clear – don’t sell me on the “experience” of this “ultimate driving machine”. I have no idea why care manufacturers sell cars on this basis. Cars are convenient, and the price you pay for that convenience is crawling along slowing in a metal box for, on aggregate, weeks of your life each year.
My objective with a car is to (safely) minimize the amount of time that I spend in it. This mean avoiding traffic jams, and so over the past few years I’ve become dependent on real-time traffic information. Because that one set of data – in my opinion one of the most underrated marvels of our modern age – it has the ability to transform a day where I spend three hours in a car into one where I spend two-and-a-half. That is valuable.
My last car was a Mazda, and they have a deal with TomTom to supply the satnav. This means that rather than the crappy “car companies have no clue about software” rubbish that comes out of every car vendor in-house labs, the Mazda’s satnav was really good.
My new car has the stock satnav – which is appalling – and also Android Auto. The price I pay for using Android Auto is the labour of having to plug the phone in every journey.
Android Auto is, if I try my hardest to be kind, a pretty poor show. But it just about works, and importantly it puts traffic information where I need it. The traffic information isn’t as good at TomTom, but it is good enough, and it’s a hundred times better than the built-in satnav.
But Android Auto up until last weekend was fairly slow. It was sluggish and crashed a lot. It was fussy and unpredictable, but despite the frustration it was able to get the data on the screen reliably enough. Android Auto is one of those projects that feels like it was thrown together by an intern.
Last weekend my phone upgraded to Android Oreo. OK, it asked me to upgrade, but I didn’t have a choice.
Overnight a tool which was just about OK became almost entirely unusable. I have a Nexus 5X, which is a little over a year old. Now, Android Auto rather than being a bit slow and irritating is virtually unusable. It now takes multiple retries to get a route programmed, and each retry takes about two minutes. So now I no longer have traffic data in the first ten minutes of any journey. That is a critical time in terms of choosing the optimal route.
All of this is a way of framing what I’m going to call “autoupdate hell”.
One of the odd things about software is that it’s never been possible to build bug-free software. The reasons for this are obvious, but nowadays we also have a problem in that the general community of software developers are clueless when it comes to building secure software. Every device that we own runs a set of software best described as a “toxic hellstew of vulnerabilities”.
This means that we need to autoupdate all of the time, lest those devices stab us in the back by providing unfettered access to a bad actor. This creates a sort of quasi-continuous delivery where users are/should be anxious to keep upgrading to the latest version at all times. I had some reservations about upgrading to Oreo, but I had to because it’s the only way to stay safe.
Like all human endeavours, every action we take has a variety of conscious and subconscious motivations. We can look at continuous delivery as being a benefit to the users – we can innovate and push updates in a cadence that the user will likely enjoy. But, there’s a side motivation in that continuous delivery lets a developer take shortcuts on QA. And the reason for this is obvious – if you make a mistake, you can back out of it with less friction that before.
(Remember when we previously had to make “gold masters” of disc images to be pressed to CD-ROM or DVD? A good number of readers of this blog will find that idea ridiculous, but if you had to risk junking a multi-thousand-dollar gold metal version of your DVD image because you’d made a mistake, you concentrated QA.)
So now we have a position where for a user to keep themselves safe, they have to update and patch as frequently as possible. But this is alongside an industry where software has to be delivered as cheaply as possible in all cases.
In short, no one in this mess but me really cares that I can no longer get timely traffic data in my car. Effectively, one morning I woke up, and some software developer that I’ve never met has broken something that I’m reliant on, for basically no benefit to me.
This is an example of when something breaks. There is a fashion in our industry now to keep changing the UI on updates. This seems to be motivated by a mix of lack of empathy for the users (no one likes their software to change), and also a motivation to make it look like software is improving constantly. No one notices when, for example, a webservice is retooled to reduce the amount of data transferred. Everyone notices when a button gets moved or hidden. So, “keep moving the buttons around and changing how things work so people think that we’re ‘up-to-the-minute’”.
The purpose of software is to delight users, relive burden, and realise opportunities. It’s great that we have tools now that make it easy to deliver new solutions to users, but those tools should not be abused to cover up from shoddy processes, or to deliver motivations that are more beneficial to the software developer as opposed to the user.
And how did I fix my Android Auto problem? I had a spare LG G4 lying around, so that’s now permanently wired in just to deliver traffic data. That’s ridiculous, and also now I don’t have a handsfree phone in my car, because Android Auto takes over the phone and stops my old phone connecting over Bluetooth to the handsfree module. Great.