Embrace the engineering metaphor

A s Wei-Lung Wang points out in his " Viewpoint " (" Beware the Engineering Metaphor, " May 2002), there are many similarities between the work of the software developer and that of the mathematician. However, I question the central thesis of the column, namely that " building software is inherently not an engineering task. " The evidence provided by Wang is that conventional engineering disciplines, including electrical and mechanical, are based on immutable laws of nature and that software lacks a similiar fixed framework. But a closer look reveals software does have a multitude of fixed frameworks—known as domains— by which it is constrained. Domains are specific areas of knowledge, and their importance to software development belatedly was recognized. Domains range from the lowest-level " implementation " domains such as Java and x86 assembly, up to application-level domains, such as accounting, airline scheduling, payroll, and employment. In fact, all software can be viewed as an implementation of some subset of one or more domains. Every domain has its constraints , or " laws. " For example, in the domain of linked lists, in order to access any element, it is necessary to traverse through all the preceding elements; the final one has nothing following it. When these domain constraints are not observed, the program fails. This may show up as an exception, illegal memory access, or garbage data, while leading some people to believe software is merely a " collection of instructions. " While the laws of a domain, such as double-entry bookkeeping, may not be immutable laws of nature, ignoring them nevertheless produces painful financial consequences. Similarly, ignoring the rules of a domain, like application security, leads to server shutdowns and loss of confidential information. Even softer domains, such as human-computer interaction, have laws that, when ignored, lead to unusable user interfaces. Regarding theoretical formaliza-tion, many of the higher-level domains have resisted an effective and usable formalization. But this does not mean these domains lack well-defined rules and constraints. The challenge to the domain engineering community is to roll out formalizations the software community can use. These formal domain theories allow exactly the kind of manipulation available to other engineering disciplines. Finally, the reason why attempts to build reusable components and libraries often fail has everything to do with the misperception that components exist in isolation. This is another place where domains can be expected to be useful. …