Sunday 12 April 2020

Radical and Normal Design

Vincenti [1] characterises radical design: “How the device should be arranged or even how it works is largely unknown. [There is] no presumption of success. The problem is to design something that will function well enough to warrant further development.” In normal design, by contrast, he writes: “The engineer knows at the outset how the device in question works, what are its customary features, and that, if properly designed along such lines, it has a good likelihood of accomplishing the desired task.”

For complex engineering products, normal design is the outcome of long evolution. In the evolutionary process many factors may be at play at every level. Society as a whole affects the demand and the rewards for particular engineering products, and constrains or supports development of relevant techniques and disciplines. Communities of specialists form, sharing knowledge in conferences, published media, and educational courses. Critics compare competing products, and engineers examine competitors' products seeking to improve their own. Supporting specialisms arise in components, in development methods and tools, and in scientific foundations.

The shape and structure of specialisation fuel the evolution of normal design: only the social existence of a specialist community enables the growth of the relevant knowledge and skills. The NATO Science Committee conference saw software engineering as a new specialism that should take its place alongside the traditional engineering branches. They were recommending—though not in these words—that software design and development should evolve from a radical to a normal engineering discipline.

Emergence of specialism and the evolution of normal design can happen when a class of product, its goals, its uses, and its substance are well-defined and bounded: examples include early Fortran compilers, smartphones, cars, TVs and airplanes. When the product is complex, specialism at the level of the complete product is indispensable: the properties and challenges of the complete product are far more than a simple combination of those of its components.

In cyber-physical systems, this imperative need for product specialism is hard to satisfy in the absence of such powerful social factors as absolute product liability. The very phrase software engineering carries an unspoken implication that the subject matter is software, and that this is an adequate and acceptable specialisation in itself. If engineers of railways, automobiles, aeroplanes, ships, cranes and suspension bridges had—absurdly—characterised their work as a single specialisation in metal engineering, would they have succeeded so well? There is a lesson here for us.

[1] Walter G Vincenti; What Engineers Know and How They Know It: Analytical Studies from Aeronautical History; The Johns Hopkins University Press, Baltimore, paperback edition, 1993.

Links to other posts:
 ← NATO and Vincenti:  The NATO conferences and a wonderful book
 ←  Software Engineering:   Engineering BY software and OF software

No comments:

Post a Comment