Consider the case of operating systems, these are certainly hierarchical. Are there not primitive operations in these systems which are indigenous to All levels? Can we not design a background machine — and hence a set of such machines — for this hierarchy of systems? If one were so designing, would not a point of departure be a set of primitives for handling interprocess communication and, in particular, for handling interrupts? For example, is it not so that the attempt to interrupt invokes in the interruptor an interrupt which will surely be processed? Is it not the case that interrupts plant ultimate interrupts for restoring the status which held prior to the given ones?
We are going to concern ourselves here with the design, production, and servicing of objects which are complex and automatic, mechanical and symbolic, whose performance and decay, breakdown and efficiency depend in only very weak ways on the laws of physics. Their structure and rigidity depend as much on the social laws governing their usage as on their internal constraints. It should be clear that when we speak of production we do not speak so much of mass production as of specialty production and mass distribution. The problems of mass producing software are clearly less important than that of producing software at all.
This is the first conference ever held on software engineering and it behooves us to take this conference quite seriously since it will likely set the tone of future work in this field in much the same way that Algol did. We should take quite seriously both the scientific and engineering components of software, but our concentration must be on the latter.
Our problems arise from demands, appetites, and our exuberant optimism. They are magnified by the unevenly trained personnel with which we work. In our deliberations we will not, I believe, be able to avoid the education problem — software engineering does not exist without software engineers. Stability in our goals, products and performances can only be achieved when accompanied by a sufficient supply of workers who are properly trained, motivated, and interchangeable. Their production should be the subject of another meeting. Our goal this week is the conversion of mushyware to firmware, to transmute our products from Jello to crystals.
8.2. MASS PRODUCED SOFTWARE COMPONENTS, BY M.D. MCILROY
ABSTRACT
Software components (routines), to be widely applicable to different machines and users, should be available in families arranged according to precision, robustness, generality and timespace performance. Existing sources of components — manufacturers, software houses, users’ groups and algorithm collections — lack the breadth of interest or coherence of purpose to assemble more than one or two members of such families, yet software production in the large would be enormously helped by the availability of spectra of high quality routines, quite as mechanical design is abetted by the existence of families of structural shapes, screws or resistors. The talk will examine the kinds of variability necessary in software components, ways of producing useful inventories, types of components that are ripe for such standardization, and methods of instituting pilot production.
The Software Industry is Not Industrialized.
We undoubtedly produce software by backward techniques. We undoubtedly get the short end of the stick in confrontations with hardware people because they are the industrialists and we are the crofters. Software production today appears in the scale of industrialization somewhere below the more backward construction industries. I think its proper place is considerably higher, and would like to investigate the prospects for mass-production techniques in software.
In the phrase ‘mass production techniques,’ my emphasis is on ‘techniques’ and not on mass production plain. Of course mass production, in the sense of limitless replication of a prototype, is trivial for software. But certain ideas from industrial technique I claim are relevant. The idea of subassemblies carries over directly and is well exploited. The idea of interchangeable parts corresponds roughly to our term ‘modularity,’ and is fitfully respected. The idea of machine tools has an analogue in assembly programs and compilers. Yet this fragile analogy is belied when we seek for analogues of other tangible symbols of mass production. There do not exist manufacturers of standard parts, much less catalogues of standard parts. One may not order parts to individual specifications of size, ruggedness, speed, capacity, precision or character set.