Join us at Device Talks Boston in October

Bigger isn’t always better

March 05, 2012

By now most people have completely forgotten Toyota’s unfortunate encounter with an angry public demanding to know why certain vehicles accelerated spontaneously and uncontrollably. The findings? Most of the accidents studied by National Highway Traffic Safety Administration (NHTSA) were apparently caused by “pedal misapplication,” and the National Aeronautics and Space Administration (NASA) could not find proof that there were electronic design flaws that caused the accelerations. Fine. But what else might we learn from the findings?

A fascinating statement is made in the NASA report: “The Toyota Electronic Throttle Control (ETC) was far more complex than expected involving hundreds of thousands of lines of software code,” which meant that they couldn’t spend as much time carefully reviewing all of the software as they had planned to.

Let that soak in: NASA is surprised at how complicated the software is for a Toyota gas pedal.

Now NASA might be a little old-fashioned, being run by old men wearing suspenders and pulling at their beards, fretting about the weather for the next launch. But let’s remember that they managed to send not one, but two rovers to Mars that operated many lifetimes longer (four years) than their original mission (three months). NASA knows software. The Autonomous Space Exploration Robotics Illustrator (IARES) software platform that the rovers used has about 300,000 lines of code.

Well, but those are just little robots that drive around like my kids’ remote controlled car.

Ahem. On another planet that’s 100 million miles away?

OK, here’s another interesting comparison from “The processing power of the F-35 has presented the electronics system developers with a formidable software challenge. The F-22 Raptor uses about 2.5 million lines of software, but the F-35 will use 5.6 million lines of code.” OK! That’s a lot of code and it makes sense because those things are wicked cool pieces of high-tech military hardware, right?

NASA is surprised at how complicated the software is for a Toyota gas pedal.

Well, apparently someone else appreciates the prestige that comes with being able to post big numbers: Chevrolet. “I thought of fighter aircraft as complex software projects at four to six million lines of code,” says Meg Selfe, IBM’s Vice President for Embedded and Complex Systems. “But the [Chevy] Volt has ten million lines.” (IBM developed a model-driven methodology for the Volt project.)

Let that soak in: a little electric car, whose four little wheels are pretty much always in contact with the ground and has a top speed of 100mph is running more software than the most advanced fighter aircraft in history, which has a top speed of Mach 1.6+.

I will grant that there are certain problems with using the number of lines of code as a metric, the details of which make drying paint seem exciting by comparison, but let’s assume that the numbers are adequate for making a rough comparison of complexity. (No offense to the people who develop paints, by the way: I love paint. I promise I’ll pick on grass growing next time.)

I think the take home message is this: less code is more. More reliability, more safety, maybe more performance. Maybe even a little more profit. Or maybe not. But here’s the thing: if you can’t examine, compare and reason about your design because of its complexity or sheer size, how are you ever going to know if it works, much less if it’s safe? Testing is important, but it can’t be conducted in such a way that every defect is discovered. I suspect that there is a “right” amount of code, of complexity, of cleverness necessary to get the job done; any less is unacceptable, and any more is an encumbrance.