Evan on Engineering Software

Peter Neumann, of the SRI Computer Science Lab (and the 1997 recipient of the Norbert Wiener Award for excellence in promoting socially responsible use of computing technology),  writes a column called Inside Risk for the Communications of the ACM.  This month, his theme is foresight: "In hindsight, the lack of foresight is an old problem that keeps recurring."  Here's a page where he gives examples of failures that occured as a result of lack of foresight.

I was thinking about this in the context of CAD systems -- how there are easily foreseeable risks that most users would rather not think about.   Users invest untold millions of dollars in creating complex CAD files that may or may not even be compatible with the next version of their CAD program of choice.

This isn't some abstract risk, that has never happened in real life.  It's all to real, and all too common.  Yet, there is no silver bullet that can remove this risk.  Yes, open data formats would help.  Yet, while I'm an outspoken advocate of open data formats, I recognize that even those that are already ostensibly open have associated with them risks due to variations in the algorithms used by applications to render that data. 

Looking back at Neumann's past columns, I found that he'd pointed out some factors that can ultimately cause risks for users.  Here are three biggies:

• Inadequate requirements and architectures. ``If a program has not been specified, it cannot be incorrect; it can only be surprising.'' (W.D. Young, W.E. Boebert, and R.Y. Kain, Proving a Computer System Secure, Scientific Honeyweller, 6, 2, 18--27, July 1985) Its composability with other programs is also likely to be surprising. Unfortunately, system specifications are always inherently incomplete, even though we desire that they completely and correctly define the relationships among modules and their interfaces, inputs, state transitions, internal state information, outputs, and exception conditions.
• Poor software engineering. The absence of sensible abstraction, modular encapsulation, information hiding, and other sound principles (e.g., J.H. Saltzer and M.D. Schroeder, The Protection of Information in Computer Systems, Proceedings of the IEEE, 63, 9, 1278--1308, September 1975, http://www.multicians.org) can seriously impede composability, as can riskful programming languages, undisciplined programming practices, and unwary use of analysis tools.
• Multiparty incompatibilities. If proactively designed, heterogeneous systems could mix and match alternative components, enabling interoperability among disparate developers. However, incompatibilities among interface assumptions, the existence of proprietary internal and external interfaces, and extreme performance degradations resulting from the inability to optimize across components can result in compositional snafus.

In my experience, all CAD software developers are subject to these problems.  The biggest companies are no better, as a general rule, than some of the smallest companies.  Still, the companies I tend to trust more in this area are the companies that at least make the effort to open their data formats.