The role of software engineering in the microcomputer revolution: An overview
William Marshall McKeeman · International Conference on Software Engineering · 1979
The title of this paper is presumptious. It presumes that software engineering exists and that you and I have a reasonably common understanding of it. It presumes that there is a microcomputer revolution and we know what it is. And it presumes that software engineering will have a different role, and that it is useful to discuss it in the new context. One way to test the presumptions is to recast the words: “The part played by non-hardware ingenuity now that very small computers dominate our concerns”. If this still seems worth discussing, then read on.The lesser aspect of the revolution that is readily apparent is that we are reliving our history in quick time. It is all the more disconcerting because we are aware of it as we do it. The list of old horrors includes irregular instruction sets, bit pushing, overambitious projects that leave the users forever dependent on stopgap systems that were never expected to be delivered, unspecified and undocumented programs, and a series of system releases that leave even stable programs awash in the sands of a shifting environment. The same historical forces that caused these messes once upon a time are doing so again. It says something about the effectiveness of our programming methods.A more serious aspect of the revolution is shown in the accompaning “graph” which depicts my opinion of the trends in software production.We are expanding so fast that industry is robbing the university cradle (the number of PhD'd granted is dropping each year), as well as pressing into service a large number of people without much formal training. The average skill level in the industry seems to me to be dropping, and along with it the quality of software.At the same time the user community is expanding to approach the entire literate population with programs running microwave ovens, automobile engines, hand calculators, telephones, airplanes, banks, gas pumps and heart patients. It is a very inelastic audience. Nearly any problem is beyond the skill of the user to understand, or work around, much less to repair.The conflict in trends is obvious.As Professor Marty Graham has pointed out, the cost of failure may well begin to dominate the industry. In many uses of computers, massive failure is fatal. It seems that there is a clear implication: programmers will be well paid, and held responsible for malpractice.It is these trends that convince me that we must redouble our efforts to regularize software engineering.It will be expensive. Specification, testing, proving, and documentation will have to improve. Those lacking the skills will have to obtain them, perhaps by returning to the university for short stays at frequent intervals. We are going to have to offer software with guarantees. It is software engineering that will make them possible.