The car is filled with slightly more mystifying tech. Somewhere I read the average modern car has 200 microprocessors. How many lines of code do they run, I wonder? No matter, the car does what it’s supposed to. Anyone who ever dealt with distributor caps, points and engine timing lights appreciates the way today’s cars work.
The GPS-bluetooth-navigation complex in the dash is another matter. It’s a mishmash of hard-to-follow menus. No matter what we do, every time we turn on the car, the podcasts on my wife’s phone start up. As for navigation, no two systems I’ve ever seen work quite the same way. At least their user interfaces don’t. Voice commands can be ambiguous, and occasionally direct you off the highway only to put you on one again.
This same overload is ruining many websites, as they now have plenty of once-simple applications. No wonder people love apps, in the sense of applications designed or adapted to work easily and quickly on the small touch screens of mobile devices. Standards like Word, Outlook, iTunes and many others have become so choked with features and choices, I’ve practically given up on them. I can figure out what they do, but it’s all too much, too fussy and time-consuming to manage.
The major media sites are chock-full of links, that you can barely navigate them without constant, unwanted and frustrating detours — most of them for ads, sponsored content and unrelated junk like “24 celebrity face-lifts gone horribly wrong” click-bait.
The drive to make software more and more functional may be behind what seems to be a disturbing trend toward failures in critical systems. They’ve happened a lot lately. In fact, it happened first rather close to home. Literally a minute before going on air one recent morning, the system that delivers scripts and audio segments failed.
At Federal News Radio, we’d gone paperless for a year, reading scripts online and saving a package of printing paper every day. Talking, trying to sound calm, ad-libbing while gesticulating wildly to my producer — that’s what a software crash causes: panic. Controlled panic, but panic nonetheless. It took the engineers an hour to fix. It turned out a buffer overflow crashed the Active Directory on which the broadcast content environment depends for user privileges. So down it went with the ship.
It was the same day United Airlines’ passenger boarding system failed, apparently the result of lingering incompatibility from the merger with Continental. It was also the same day that the New York Stock Exchange famously experienced an hours-long crash, reportedly because of a network connectivity issue. Earlier in the month, a hardware-software interaction interrupted the State Department’s globally-distributed system for issuing visas for two weeks.
Successive program managers for the F-35 fighters have all complained they can’t get the software development for this fussy and delicate airplane in any sort of predictable schedule. Yet the plane can’t fly and be maintained without its software.
In short, two problems linger with software controlled systems: they can be difficult to interact with, and in their complexity, they produce effects even expert operators can’t foresee.
I believe this is the basis for the spreading appeal of agile development. It forces people to develop in pieces small enough that people can keep track of what is going on in ways that the users can assimilate easily.
Complexity, or the desire to avoid it, is why people like apps on mobile devices. I confess to checking Buzzfeed on my phone when I’m bored. The content is inane, but it’s such a fast, simple app, like eating gumdrops. I recently checked out the regular website of Buzzfeed, and sure enough, it’s a confusing kaleidoscope. Although, an ice cream cone swaddled in Cocoa Krispies does sound good.
