Testing Lessons Learned From Toyota
Retired NASA Astronaut Mike Mullane* (pictured left) said it best when he asked: “Why is there never time to do it right, but always time to do it over?” He could have easily been talking about the recent problems Toyota has been dealing with, but he wasn’t. He was talking about today’s software companies.
Conversely, this recent article from The Economist could just as well be about today’s software companies, but it isn’t. It is about Toyota’s recent problems.
Like everyone else, the author wants to know how the auto giant could so quickly lose its reputation for safety and quality (things that can happen to ANY company if they are not careful). The culprit? You guessed it: software bugs.
Instead (of trying to keep pace with competitors), two recent trends, both software related, hint at the reason behind Toyota’s unexpected decline. One is the shortening of product-development cycles generally in the car industry. These are down from a typical four or five years to little more than 15 months, thanks to computer-aided design and manufacturing, and the virtual simulation of the resulting products. To save money and time, Toyota has even dispensed on occasion with building test “mules” and other engineering prototypes.
The other trend is the wholesale replacement of mechanical components with electronic controls. It started with ignition systems, then spread to air-conditioning, cruise-control, engine-management, throttle linkages, transmissions, and now the steering and braking systems. Drive-by-wire is not cheap, but it reduces the number of components needed to do the job. It also allows them to do extra things as well as to compensate for wear and changes in driving style and road conditions.
But software is not hardware, and software “engineers”, despite their appropriation of the name, are a different breed from the sort that bash metal. Programming digital controllers is not one of Toyota’s core competences. Even with the most diligent of testing, bugs will always find their way into software. Right now, it seems Toyota is learning that lesson the hard way.
But Toyota isn’t the only one learning lessons the hard way. As it turns out, the NHTSA does not have one single software engineer on the payroll to analyze the Toyota situation properly. CarConnection.com puts this into context:
If it cannot properly analyze those systems, or even understand at a deep-code level how they work, then the agency is useless at overseeing the entire “Safety” part of its mandate.
The agency has an annual budget of more than $800 million, and it employs 635 thousands of people. That not a single one of them is an EE or software engineer borders on the criminally insane.
So what have we learned from all this? Basically, that it’s okay to launch on extremely short development cycles if – and only if – the product has been tested extensively beforehand. Also, since there is no safety net, you are on your own when it comes to ensuring a quality. No one else can do it for you.
*By the way, Mike Mullane – a terrific writer and lecturer - was the keynote speaker at STPCon this past Fall. For a primer on his career and general philosophy, you should watch his appearance on The Daily Show.








[...] light of Toyota’s recent quality issues, the number of formal consumer complaints has risen above the norm. To make matters worse, Toyota [...]
[...] light of Toyota’s recent quality issues, the number of formal consumer complaints has risen above the norm. To make matters worse, Toyota [...]