Culture: It's The Fault of Software

TORONTO, ONTARIO - While I do not discount Henry Petroski's contention discussed earlier this week that the role of engineering is not understood and appreciated in North American culture, I probably differ from him in assessing the origin of that gap. I contend that engineers themselves created the problem by their behavior in engineering software.

A major component of the problem seen by Petroski is that engineering functions as the afterthought after scientific discovery that concludes a product is possible. The work necessary to turn that discovery into a reliable, marketable product seems inevitable instead of a challenge requiring skilled labor, time, and money. There is a small degree of truth to this--I've often joked that "any engineering problem is solvable given enough time and money--though you may not like the solution." Underlying the joke is the fact that skill and experience is required to minimize the time and money spent, and that within reasonable limits of each, there may not be something that meets the requirements for the product to have a market. That's why product engineers stick to processes of varying rigor (depending on the product) that avoid spending too much time and money on something that will likely not satisfy the market demand.

Of all the engineering disciplines, software is the one in which that ultimate failure is least likely in most applications, especially applications intended for mass consumer markets (as opposed to those running safety devices). Thus, for those markets, the processes developed for general product development have increasingly not been followed. I know software developers that not only don't use ISO or IEEE standards for quality processes or risk analysis, but they've never even encountered them anytime in their education or careers. The business people liked the shortcuts, since they appeared to save money and time. The result is software hitting the market from major companies that wouldn't have passed muster as an internal beta test version under most robust quality processes. The world became the beta testers of poor-quality software.

Gradually, this lack of discipline has extended to engineering fields beyond software. My personal educational exposure to concepts of risk management and quality processes was minimal, though I've had plenty of exposure in industry. The result is a similar, if less extreme, version of the same impact on the quality of product reaching the consumer. That gives the average person little reason to respect engineers.

Clearly, the general public is capable of appreciating good engineering. The success of Apple, which emphasizes ease-of-use and general user interface (or "user experience") issues in its products, demonstrates that engineering done well can make money and gain widespread adoption. Respected engineering has long influenced the automobile industry--not just in high-performance sports cars but in the traditionally well-engineered Japanese vehicles. I know people that wouldn't even look at other manufacturers after they were impressed with their Honda or Toyota.

In fact, it doesn't surprise me at all that it's starting to look like the root of Toyota's current quality problems may actually come down to poor safety features in its software. Just like engineering looks like an afterthought relative to basic scientific research, software can look like an afterthought relative to hardware engineering. Under pressure from cost-cutting management, it's easiest to try to take shortcuts on the quality of software. As Toyota may be learning the hard way, this is a serious mistake. Quality systems need to apply to every last aspect of a product; the quality of the overall product will be that of its weakest aspect.

Of course, engineers usually understand that. It's the accounting-trained businesspeople that want to cut costs in a way that inevitably leads to trouble. That may be the biggest problem for engineers trying to gain understanding and respect for their craft--as long as management imposes product decisions that ignore engineering input, there's little opportunity for them to demonstrate why they should be respected. The only way to break that circle is education, and considering who runs business schools, I don't see how it will happen. Henry Petroski may have a long battle.