Episode Summary:
Almost everything we use in daily life is software control. Mechanical and analog actuation and feedback control systems are rapidly disappearing, and everything from a smartwatch to a turbofan engine relies on thousands, sometimes millions of lines of code to function properly. Traditionally, the people that write the code have operated in a sort of vacuum, free to generate algorithms as they wish, and able to impose significant constraints on what the systems’ algorithms control, and on the humans that have to interface with them.
Increasingly, the friction between the “wetware” of the human user and the needs of the machine is building excessive complexity and cost into everything from using a ridesharing service to planning a lunar trajectory. What can be done? Jim Anderton has some definite opinions.
Access all episodes of End of the Line on engineering.com TV along with all of our other series.
Transcript of this week's show:
This is my smartwatch. There’s nothing particularly unusual about it and I won’t mention the manufacturer, although many of you will recognize it. I’m not mentioning the manufacturer because this is not about who builds things, but rather about who codes them. I need this watch to do two things. Tell me what time it is and tell me how he steps I take throughout the day. It’s capable of generating vastly more data and delivering it in very interesting ways. It can measure my heart rate, prompt me to get out of my chair and, and simulate track running by laps or distance traveled. It can tell me who’s calling on my smart phone. All that’s terrific, and it would be perfect, except for the unfortunate habit it has of occasionally changing the display face from digital to analog display, seemingly randomly, forcing me to manually reset it to my preferred digital display. Now this is hardly an uncommon phenomenon. My Android smart phone does things in an un-commanded way occasionally, and so does my laptop. And my tablet. We are all conditioned to accept these glitches as the inevitable consequence of using equipment, which is coded with hundreds of thousands, perhaps millions of lines of code, something which we acknowledge as impossible to fully debug. We accept inconveniences that this creates and we’re tolerant of becoming beta testers, because we want the convenience that these devices offer. If the systems fail on airliners, as has happened recently however, people can die. No, I’m not trying to equate my frustration with my smartwatch with Boeing’s difficulties with the MCAS system on their 737 Max, but the simple fact is that in my opinion coders have gotten away with mistakes that would never have been tolerated in an analog or mechanical engineering world. The basic assumption of all good engineering design is that the systems should function using the simplest and most reliable technology available. When systems become excessively complex, bad things happen. Automatic transmissions in the 1980s and 90s were hybrids of electric analog devices and used hydraulic logic. They were service and maintenance nightmares that were barely understood even by the engineers that built them. They’re more complex today because they’re code controlled and automatic transmission service is notoriously expensive, so much so that otherwise serviceable light vehicles frequently end up in scrap yards because of the high cost of a rebuild. That is a systemic failure in my book, just as the annoying habit of this watch to change its display mode arbitrarily is a failure too. If you rent a car these days the wireless key fob and the engine starting button has to be studied, examined, thought about in ways that a key never did. Remember when you were a kid and the family VCR flashed 12:00 o’clock all day long? The point is simple: if you’re coding these systems, the low cost of adding complexity doesn’t mean that it’s a good idea to do so. Reliability is still job one, whether it’s a watch or an airliner and since code is essentially virtual, there really isn’t a good excuse for programs that don’t work. Code that can’t be tested for reliability is bad code. These days we have a war on Covid 19, a war on drugs, war on terror, I propose that we have a war on bloated code. A war on needless complexity. Devices like this aren’t cutting it. If we could do it in the automotive industry with kinematics, hydraulics and DC current, you can do with keystrokes.