I’m flying to San Francisco. Right now. As we speak. I figured Richard Branson needed a few more bucks so I hopped on one of those shiny new A320s that everyone’s been talking about. This isn’t a review per se, but I think a few things are worth mentioning.
First things first. The planes are pretty. Say what you want about the quality of LED light, but seeing blue overhead really takes the edge off the claustraphobia. The designer must have known we were flying to San Francisco, because the wall wash was the gayest pink lighting I’ve seen. And I’ve been to clubs in Chelsea.
OK. Enough chit-chat, let’s get to the point. There is a word that should never, ever be associated with an industry in the business of putting people in aluminum tubes traveling at a terrific clip while five miles above cold, hard rock: the C word. Even the IT guys bunkered up in airline data centers outside Topeka don’t say it. The servers don’t c%!*h, they have “unannounced service interruptions.” Or “unscheduled downtime.” Or something.
So I was surprised to see that the seat-back touch screens had a different word on them. I see this word on application splash screens before my computer experiences a fiery mid-air collision. The B word. Yeah, you’re right, I probably won’t jinx anything if I say this one. Beta. Beta. Beta beta beta.
Right. Two things. First, why is everyone saying beta when they really mean broken? I mean saying an airplane suffered mechanical fragmentation doesn’t change the fact that it’s in a million pieces and strewn across a field. And second, I really hope the electronic engine controls have had a few more revision cycles. OK, I do actually understand the difference between mission-critical software and, well, the kind that doesn’t kill you when it segfaults. So what is it about software that we interact with that makes it so much harder to write than the software that makes sure the wing flaps move when the pilot jiggles the control stick?
Let’s start with the control systems. This software is usually embedded, usually has input in expected ranges, and is usually written by engineers. Not people who call themselves “software engineers,” but actual engineers that studied, you know, engineering. Mission-critical software is carefully specified, written to exacting standards and tested thoroughly.
So why isn’t consumer software like that? Well first of all, those same engineers are the ones responsible for the hellish experience of programming your VCR. These folks spend their time talking to machines. They can do it better than anyone else, but it makes their interactions with actual people kind of awkward. Trust me, you don’t want to use software designed by someone who knows the difference between a bushing and a bearing—because they’ll expect you to know it too.
Software that doesn’t fuck up is different from software that you’d actually want to touch because different types of people write it. Not only is getting input from an airspeed sensor far easier than reacting to human actions, but the airspeed sensor is not likely to get pissed off when things don’t go its way. Engineers write code that’s unlikely to fail, but in order to make software that doesn’t drive people crazy, the programmer should have a pretty solid understanding of psychology.
What’s the moral of the story? Well, in this case, beta is an excuse for software that has very little understanding of the user’s psychology. Remember that, kids. In order to write software that interacts with a machine, you need to understand what’s going on inside that machine. If, instead, your software is intended for human interactions, you’d damn better understand what’s happening in the user’s head on more than a superficial level.