- Email: [email protected]
Portrait of a (software) engineer
J. SYSTEMS SOFTWARE 1991; IS: 91-100
91
Controversy Corner It is the intention of the Journal of Systems and Software to publish, from time to time, articles cut from a different mold. This is one in that series. The object of the Controversy Corner articles is not so much to present information as to stimulate thought. Topics chosen for this coverage are not traditional formal discussions of research work, but rather are informal presentations of key issues in the systems and software world.
Portrait
of a (Software)
This series will succeed only to the extent that it
stimulates not just thought, but action. If you have a strong reaction to the article that follows, either positive or negative, write to Robert L. Glass, Editor, Journal of Systems and Software, Computing Trends, P.O. Box 213, State College, PA 16804. We will publish the best of the responses as Controversy Revisited.
Engineer
Robert L. Baber Bad homburg,
v.d,H.,
Germany
The terms “software engineering” and “software engineer” have been and are still being bandied about in ways with which many engineers in the classical engineering fields take exception. In these engineers’ view, our applying the term ~‘engineeringJ’ to software development indicates that we software developers do not understand what “engineering” means and is really all about. They suspect that we are simply trying to take advantage of the professional reputation they have earned by good, hard work, without our taking the time and trouble to acquire a comparable level of knowledge, qualification, and capability. What is engineering? What does the classical engineer perceive to be the essence of his profession? How does he view his professional work? What is his role in society and what is the nature of his relationAddress correspondence to Robert L. Baber, Landgraf Gustav Ring 5, D-6380 Bad Homburg, v.d.H.. Germany 0 Elsevier Science Publishing Co., Inc. 6% Avenue of the Americas, New York. NY 10010
ship with clients and third parties, especially with regard to the responsibilities assumed by each7 How does he prepare for his life’s work? To what extent and in what ways does he employ the knowledge acquired during his education in later professional practice? These and related questions are considered in this article. While we are particularly interested in the implications of the answers with regard to software development, our attention will be mainly directed to engineering-in the traditional sense-in general.
Engineering is born of both practice-fabrica-Ed thePractice is a mechanical facility, developed through exercise. Theory is the ability to describe and explain the designed object.
ory-ratiocinatio.
-Marcus
Vitruvius Pollio, ca. 2.5 B.C. (paraphrased translation)
OIW1212/91/$3.50
92
J. SYSTEMS SOFTWARE 1991; 15: 91-100
R. L. Baber
The programmer’s task is not just to write down a program. His main task is to give a formal proof that the program he proposes meets the equally formal functional specification. -Edsger
W. Dijkstra, 1989 A.D.
INTRODUCTION In recent years it has become increasingly popular to talk of “software engineering” and to use this term ever more ~equently in connection with various software development activities. This trend is motivated, it seems to me, by a desire to obtain the same benefits achieved in the classical engineering fields, in particular, a high ievel of design quality. To some, it might even appear that we software developers subconsciously believe (or simply hope?) that if we use the word “engineering” often enough, our software will somehow become as reliable as the designs created by classical engineers. I do not believe that this result can be achieved in this way. We will achieve a quality in our work comparable to that long since achieved in the classical engineering fields not by calling our work “engineering, ” but by really doing engineering. The difference is great, significant, and too often overlooked by software developers. What do I mean by “software engineering”? This question can be best answered by considering first and primarily the question, what do I mean by “engineering”? 1. THE ESSENCE OF ENGINEERING
What is the essence of engineering as understood by classical engineers? The application of scientific knowledge and principles to the task of designing and constructing an object, machine, or system of economic value is probably the most characteristic aspect of engineering. Especially noteworthy is that the engineer employs a scientific, theoretical foundation to verify-by systematic calculation before the object is actually built-that a proposed design will satisfy the specifications. This step gives rise to the high level of reliability to which the engineer, his clients, and society have become accustomed. It is a prerequisite for the widespread application of potentially dangerous machines, systems, etc., in society. The engineer’s goal is a practical result of economic value to his client. The engineer is concerned with the scientific theory underlying his particular field insofar as it enables him to design a more effective, efficient and/or reliable system or to reduce the time and efTort needed to design or build the system. He recognizes the value of a Vitruvian balance between theory and prac-
tice: Those whose abilities are limited to practical skills (fabrica) never achieve much of real significance. Those who, on the other hand, rely only on their knowledge of the theory (ratiocinatio) mistake the shadow of the object for the object itself. Only those who are able to apply well developed capabilities in both areas to the job to be done will accomplish it with honor. Both aspects, fabrica and ratiocinatio, are of equal-and critical-importance in professional practice [34]. Because the objects and systems designed by engineers are usually potentially dangerous-human deaths and considerable financial loss can be caused by design errors or malfunction-society permits only qualified persons to practice engineering. Furthermore, certain requirements are placed on those admitted to professional engineering practice. These restrictions and requirements vary considerably from country to country, from one field to another, and between private and corporate engineering practice. At the minimum, the prospective engineer must demonstrate that he has an adequate active command of the theoretical foundation of his field. This requirement is fulfilled by obtaining a relevant academic degree or by passing a professional examination. In some cases both are required. Often, the prospective engineer must also demonstrate a specific level of practical proficiency. A certain mathematical and theoretical knowledge-including both a common foundation and material specific to the individual technical field in question -has been found to be a prerequisite enabling the engineer to satisfy his clients’ and society’s demands for reliability and freedom from design errors. Knowledge of the underlying theory is also of direct practical value to the individual engineer; without it, he would simply not be able to compete successfully in the marketplace for engineering services. In short, society has found that it is better-in terms of overall costs incurred and benefits achieved-to make a significant investment in its engineers’ initial education. In the long run, this investment pays off well for all concerned. 2. THE ENGINEER’S RESPONSIBILITY
For several reasons the engineer takes his responsibility to his client and to potentially affected third parties seriously. First, the engineer enters into a legal contract with his client to deliver a design meeting certain specifications; if he fails to do so, i.e., if his design does not satisfy the specifications, he can be held liable for non~ifillment of contract. Second, his design must satisfy various requirements es~blished to protect the public from potential dangers arising from the construction and utilization of the object or system in question.
Portrait of a Software Engineer Third, significant shortcomings in the quality of his work can lead to the withdrawal or restriction of his professional recognition and his legal right to practice his profession. Finally, but not necessarily least important, most engineers take pride in their work and feel idealistically rewarded when they create an excellent design, especially when their peers also recognize the quality of their work. This attitude toward responsibility is reflected in the code of ethics to which most engineers are requested and many are required to subscribe. While such codes of ethics vary from country to country, from field to field, and from one professional organization to another, they do have the following important features in common: The engineer recognizes that his professional work affects the quality of life for all members of our technologically based society (not just his immediate clients). He accepts full responsibility for his actions and the results of his work, with respect to both his clients and the public. He agrees not to make exaggerated claims, not to accept assignments beyond his professional capabilities and qualifications, and to disclose any relevant limitations in his ability to perform the work in question before accepting an assignment. He agrees to maintain honest relations with all with whom he deals professionally, disclosing in advance any circumstances which could lead to a conflict of interest. He agrees to maintain and increase as required his professional knowledge and skills. In short, he agrees to take all appropriate steps to earn and ensure the continuing trust placed in him by his clients, professional colleagues, and society as a whole [7, 8, 211. The legal nature of engineering responsibility differs, certainly, between corporate and private professional practice. But even in corporate practice, fulfilling this responsibility ultimately derives from the decisions and actions of individual engineers. Under certain circumstances, at least, a professionally qualified engineer (usually an employee of the corporation in question) must personally certify that the design meets certain requirements by signing an engineering release before the corporation manufactures and supplies the system to its customers (see also Section 4 below). While legal responsibility lies largely with the corporation, some legal-and considerable professional-responsibility remains with the individual engineer. The engineer’s attitude toward his professional responsibility does, of course, give rise to a certain dichotomy. On the one hand, as stated above, the engineer takes his responsibility seriously. On the other hand, he realizes that he is a fallible human being. A certain frustration and anxiety results. Perhaps more important, however, this problem-ensuring that the
J. SYSTEMS SOFTWARE 1991: 15: 91-100
93
results (designs) are reliable despite the fact that the designers are fallible-represents a challenge which the profession and the legal and societal infrastructure accept and by and large successfully meet by a variety of means. The scientific theory underlying the field, formal reviews of the design by official certification authorities, other organizational checks, etc., play important roles in this respect. The engineer, recognizing his own fallibility, does not actually expect to get all aspects of all designs in his entire career right, but he does expect and try hard to get each individual one right. Just because one cannot expect to actually reach a goal does not mean that one should not bother to try to get as close as possible to it. And, of course, errors with particularly serious consequences must be avoided by taking special and extra precautionary steps. Expressed more mathematically, the engineer realizes that while an error rate identical to zero is not achievable, the greatest lower bound of the error rate is equal to zero. It follows that one can achieve an error rate arbitrarily close to zero. So the engineer tries, aiming for zero. The professional engineer’s attitude toward his responsibility and the theoretical and scientific foundation for his work are mutually interdependent. The scientific basis for his work enables the engineer in principle to verify analytically and in a mechanistic way that his design will satisfy the specifications. This, in turn, (again, in principle) eliminates the personal risk associated with the acceptance of responsibility for the correctness of his design. Thus, his command of the relevant scientific foundation and his ability to apply it to practical design problems enable the engineer to accept responsibility for his design without assuming undue personal risk. On the other hand, society’s need to reduce the risk of damage to property and loss of life due to faulty designs is a primary reason for holding the engineer responsible for the quality of his designs, which in turn gives rise to the need to understand thoroughly the technical and scientific nature of the design work being undertaken. In short, the scientific foundation for his work enables the engineer in principle to get his designs right and to accept responsibility therefor. Some room for error still exists, of course, arising from carelessness, negligence, or inadequate knowledge, e.g., of recent technological developments. To a certain extent, organizing his calculations and work appropriately can help to reduce the likelihood of such errors, but in the final analysis some chance for error remains which only the engineer’s determined effort-and reviews conducted by others-can reduce further.
94
R. L. Baber
J. SYSTEMS SOFTWARE 1991: 15: 91-100
3. THE EDUCATION
OF THE ENGINEER
The engineer prepares for his life’s work by completing a formal tertiary academic education of several years duration. During this time he learns the theoretical and scientific foundation of his field so thoroughly and uses it so extensively to solve realistic exercises that its application becomes almost a reflex action. (For example, an electrical engineering graduate who has subsequently pursued a career in another field can typically interpret and explain Maxwell’s equations even though he has not used them in decades.) This type of knowledge is particularly important, for it is not subject to change and will remain valid and applicable throughout the engineer’s career. In laboratory work, the student engineer also acquires a sense of practical reality. In particular, he becomes familiar with practical limitations deriving from the current state of the technology. While such an appreciation of practical reality and limitations is important, this knowledge is subject to change and is, therefore, of less ~ndament~ importance. In fact, one of the tasks of many engineers is to reduce such limitations and push the forefront of the practically attainable (the “state of the art”) into previously unattainable regions. In the fields of aeronautical and electrical engineering, for example, rather astounding advances have been made in the past several decades. Engineers in these fields are now routinely designing devices and systems which were well beyond the limits of technology when they were students. When the engineering student completes his academic studies, he has acquired most of the basic scientific knowledge he will need during his career. Just as important, he has learned how to learn the additional material he will find that he needs later. While he will have acquired some practical experience, it is primarily in this area that his preparation for professional practice is incomplete. In particular, he will have dealt mainly with small systems or subsystems and will have had no or only superficial contact with really large engineering design projects, e.g., requiring many years of engineering effort to complete. Experience in the classical engineering fields in the century or so of their existence strongly suggests that it is more efficient and effective to acquire a thorough knowledge of the theoretical foundation first and then to obtain practical experience. The young engineer with a good knowledge of the theory will benefit much more from, say, a year of experience on the job than would someone without the theoretical knowledge. His theoretical knowledge helps him in drawing conclusions from his observations on the job and sharpens his perception, often suggesting what to look for. In con-
trast, practical experience helps less in learning the theory, with the possible exception of motivational effects. (Sanding several months on the job doing a task the hard way and then subsequently learning some theoretical material which reduces the task to a severalday job is a sobering experience which tends to motivate the student to acquire more fundamental ~owledge.) After completing his formal academic studies, the new engineer must acquire a few years experience before he can justly claim full professional status. Particularly in this regard can one observe considerable differences between countries, technical fields, professional organizations, etc., but in most cases a certain length of certified experience is required before an engineering society will promote a member to full or advanced professional status. It is usually considered irn~~nt that the new engineer’s initial experience be planned to include both a certain breadth of exposure as well as significant depth in selected areas. Furthermore, he should be supervised and guided by an experienced engineer who acts as a sort of informal tutor. The pedagogical goal is to structure this initial experience so that the new engineer benefits as much from it and increases his abilities and qualifications as rapidly as possible. In order to achieve this goal, the work assigned should have a truly professional content and make a significant contribution to the larger projects of which it is a part. Even after attaining full professional status, the engineer’s education is still not complete-it is never really complete. The successful engineer who is interested in his work never stops learning. This is, in fact, one of the cha~cteristics of a professional field which distinguishes it from a craft or non-professional technical occupation. The true professional continues to advance the state of the “art” and his own qualifications. In his continuing education, the professional learns not only new facts or technical skills, e.g., how to use a computerized drawing system (the architect), how to write in’ a new programming language (the software engineer), how to use an automated blood pressure meter (the physician), etc., but, more important, he tries to increase his ~ndamen~ u~de~~tffndjng of the phenomena of interest and concern in his field. 4. ENGINEERING DESIGN The engineering design task, in the narrow sense, begins with an external specification of the object to be designed and ends with a suitably complete description of its internal structure-the internal specification. In the broader sense, engineering design work includes defining the external specification. Because the external s~cification embodies the technical essence of the
Portrait of a Software Engineer agreement (contract) between the design engineer and his client, an appropriate dialogue and negotiation between the two are an important part of this preliminary phase of the design work. The engineering design task can be thought of as a creative process translating one formal description (mathematical model) of the object to another formal description, the latter being much more detailed and reflecting the internal structure. The design engineer has two obligations to fulfill: 1) to deliver the design (the internal s~ci~cation) and 2) to demonstrate analytically that his internal specification fulfills, i.e., correctly implements, the given external specification. The latter step-convincing himself and other engineers by technical and scientific calculations and arguments, before actually building the object, that the internal specification implements the external specification-is in many engineering fields a prerequisite for obtaining a building permit or an operating license. In all classical engineering fields, both of the above tasks are accepted as the engineer’s obligations. As Prof. Dijkstra clearly stated {see the quo~tion at the ~ginning of this article), the software developer has the same two obligations FI31. Correspondingly, the engineering design task consists of two phases. The first phase, creating the internal specification, is primarily of a creative nature. Scientific and technical considerations play a role, to be sure, and can provide useful guidelines, but imagination, innovation, new ideas, etc., are important, appropriate, and desired. In this creative, non-mechanistic phase, the engineer makes many design decisions, finally selecting one of the many possible designs which would fulfill the external s~~ifi~ation. The second phase, on the other hand, consists of a predominantly determinate and mechanistic analysis, structured in a standard way and following established rules and procedures. The goal of the second phase is to verify, generally by appropriate calculations, that the design satisfies the requirements set down in the external specification. Major improvements and technological breakthroughs derive from innovation in the creative phase. The reliability characteristic of professional engineering derives from proficiency and skill in the application of the theoretical and scientific foundation mentioned earlier to the task of formally verifying that the design (internal specification) fulfills the external specification. The external specification deals with 1) those externally observable characteristics and properties of the object to be designed which are of im~~nce or concern to the user (the “performance” of the system) and 2) those environmental conditions which may affect the object and its ability to deliver the desired perfor-
J. SYSTEMS SOFTWARE 1991; 15: 91-100
95
mance. The environmental conditions include, but are not limited to, those under the control of the users. In practice, an external specification is never an absolute statement, e.g., “the bridge will withstand the applied Ioad,” but is always a conditions statement, e.g., “if the total load does not exceed X tons and if no axle load exceeds Y tons and if no earthquake exceeding scale 2 occurs in the immediate vicinity and if the ambient temperature is between A and B degrees centigrade and if the wind speed does not exceed C km/hr and if . . . , then the bridge will withs~nd the applied load.” The conditions are important and often extensive, even more extensive than the statements about the performance characteristics. They are an integral part of the external specification. Overlooking some of these conditions can easily lead to an unsatisfactory design. The final specification often explicitly includes conditions about internal components (it always implicitly presupposes them). Obviously, the design engineer cannot be held responsible for everything and all eventualities. The conditions in the external specification serve to define the boundaries between the res~nsibilities of the engineer, his client, and third parties, expiicitly taking into account relevant factors not under the control of anyone (“force majeure” and “acts of God” in legal terminology). The above comments apply not only to the classical engin~ring fields, but are equally valid in the specific context of software. The external specification of a program segment or entire program also typically takes on the form of a conditional statement: If the values of the program variables (and, where applicable, input data and elements of data files) fulfill a certain condition (called the precondition) before the program is executed, then the values of the program variables, output data, and elements of data files afterward will satisfy another condition (the postcondition). Not infrequently, the external specification consists of a hierarchy of such conditions statements, e.g., in the following simplified part of a specification for an aircraft: If all four engines are functioning normally, i.e. deliver the specified thrust, then the aircraft will be able to reach and maintain level flight at any altitude up to 12000 m and a speed of at least 900 km/hr. and If at least three engines are functioning normally, then the aircraft will be able to reach and maintain level flight at any altitude up to 8000 m and a speed of at least 5.50 km/hr. and If at least two engines are functioning normally, then the
96
R. L. Baber
J. SYSTEMS SOFTWARE 1991; 1.5: 91-100
aircraft will be able to maintain stable flight at any altitude
up to 2000 m. Note that a certain degradation of performance is specifically provided for in the specification; it is not a random result of the design process. In software development, quite comparable situations arise, especially with regard to “correct” and “incorrect” inputs entered by the user, for example: If the data entered by the user is “correct” (which must be unambiguouslydefined in another part of the specification), then the system will print out report X (also described elsewhere in the specification). and
If the data entered by the user is “incorrect”,
then the system will display an error message as specified in table X (part of the specification).
Certain data may represent an error condition in terms of the application and the user, but to the designer “incorrect” input data are not “wrong” or “erroneous” in any meaningful sense. They, too, must be processed in a very specific way with a result as stipulated in the specification. The internal specification states what components are to make up the object being designed and how those components are to be interconnected. It describes the interfaces between the components and, in particular, the characteristics of the components upon which the correctness of the overall design of the object depends. These characteristics are, in turn, external specifications of the individual components. In the case of a design of a bridge, for example, the internal specification will consist of a plan for connecting the individual girders in a particular way together with statements about the dimensions, strengths, etc., of the individual girders. The engineer will also include a calculation showing that the requirements laid down in the external specification will be satisfied by his design, in particular, that the bridge will support itself and the intended load without collapsing (under the conditions assumed and explicitly stated). Such calculations are based on the scientific theory underlying the field in question-here, statics (a special case of Newton’s laws). In the case of a computer program, the internal specification will consist of its code and definitions of the interfaces between it and the subprograms it calls (pre- and postconditions and complete lists of the variables modified by the subprograms). Each description of an interface is, in effect, an external specification of the called subprogram. The software engineer who views his task as Prof. Dijkstra defined it [13] will give a logical proof that the program’s external specification
will be met, assuming of course that the called subprograms satisfy their interface specifications, that the interpreter or compiler fulfills its specifications, that the hardware functions as assumed, etc. In engineering design projects, a responsible engineer is typically expected to sign an official release of the design when it is completed. Often only an engineer possessing certain legally recognized qualifications is authorized to sign such a release. By signing the release he formally accepts professional responsibility for the correctness, safety, suitability, etc., of the design. In a certain sense he stakes his professional reputation on the design and its conformity with the specifications. This formal step is typically of legal significance. Signing a formal release of the design can have other, informal, even personal significance to the engineer. At least some engineers experience a sense of accomplishment and a feeling of pride associated with assuming formal responsibility for the design. This act symbolizes the considerable effort leading to a successful result of which the entire design team can be proud. It involves a certain assumption of risk, to be sure, but that risk is estimable and in a certain general sense limited (and therefore acceptable) because the engineer knows why and to what extent he can have confidence in the design. The scientific and theoretical foundation for his work and the mathematical models he uses enable him to determine analytically under what conditions the design will-and will not-perform as required. In summary, perhaps the two most fundamentally important prerequisites for professional engineering practice are 1) the theoretical and scientific foundation which the engineer thoroughly understands and continually applies in his work and 2) a highly developed sense of responsibility toward his clients and the public. The first prerequisite enables the engineer to assume and discharge the obligations deriving from the second. In this regard, engineering is directly comparable to other professions such as medicine and law.
5. THE ENGINEER’S PROFESSIONAL ENVIRONMENT The engineer is embedded in an environment which influences, supports and restricts his professional activities. The most important elements of his professional (as opposed to commercial) environment are the academic institutions which educate engineers (see Section 3), the legal structure regulating professional practice, and the professional associations. These three elements are typically formally interrelated. Engineers working as employees are also, of course, embedded in a corporate environment reflecting both commercial and pro-
Portrait of a Software Engineer
fessional interests and concerns. Typically, the professional aspects of the corporate environment consist of norms set by the external professional structure which have been selected, specialized, and adapted to the corporation’s particular business. We will, therefore, restrict our attention here to those external professional influences. Particularly in the area of the professional associations can one find significant differences between the classical engineering fields on the one hand and software development on the other. A professional engineering society typically restricts full membership to those who fulfill certain formal requirements. Interest in the field is not sufficient. The minimum requirement for full membership is a relevant academic degree or its equivalent, e.g., passing a special examination. Many such associations require that applicants formally subscribe to a code of ethics and professional conduct. Furthermore, engineering societies in many countries have several grades of membership. Only after acquiring a certain amount of practical experience (certified by other engineers with regard to quantity and quality) is one eligible for promotion to a higher grade of membership. Professional engineering societies typically have procedures for reprimanding members who practice in a manner judged to be incompetent, inadequate, questionable, or unethical or which reflects negatively on the profession. In extreme cases, they may be expelled from membership. In some countries, such action effectively limits the professional activities in which the engineer affected may subsequently legally engage. The use of certain forms of engineering titles is restricted by law and unauthorized persons using them are subject to prosecution. For example, the title “Professional Engineer” (P.E.) is protected in the U.S.A.; “Chartered Engineer” (C.Eng.) in the United Kingdom; and “Ingenieur” (engineer) in the Federal Republic of Germany. Most associations of computing specialists have no formal prerequisites for membership. Anyone who is interested in the field and who is willing to pay the membership fee may join. While some of these associations may suggest or recommend certain codes of ethics and conduct, they cannot effectively enforce them. Associations of this type differ from the traditional professional societies in fundamental ways. A few associations of computing specialists exist which represent intermediate organizational forms. Some engineering societies have subgroups for members with a particular interest in computing, e.g., the Computer Society of the Institute of Electrical and Electronics Engineers (IEEE) in the U.S.A. Such subgroups of engineering societies may or may not admit
J. SYSTEMS SOFTWARE 1991; 15: 91-100
97
as members persons not qualified for full membership in the parent body. The British Computer Society, originally a non-professional computing association, was an example of another intermediate organizational form until it was admitted to the Engineering Council as a professional engineering society in 1990. Every association’s rules and regulations regarding admission to membership, maintenance of membership, promotion to higher grades, etc., reflect its members’ view of their own role, their attitude toward their work, and their responsibility to clients, other practitioners and third parties. They also reflect how seriously the members take their work and how proud they are of the results of their work. If the field of software development is to become a full-fledged engineering discipline, its professional associations must make corresponding adjustments in their structure, rules, regulations, etc. The path which this development will take is currently unclear. The subgroups of existing professional engineering societies could assume this role for software developers (there are some signs of this occurring in the U.S. A.). Or existing associations of computing specialists could reorient themselves to satisfy the needs of professional computing and software engineers (as in the U.K.). Alternatively, new professional engineering associations could be formed. 6. THE SOFTWARE DEVELOPER: AN ENGINEER? To what extent does the above portrait of an engineer apply to us software developers today? In what ways do we fall short of being engineers? Perhaps most telling is the view engineers in the classical fields have of software developers with whom they have worked jointly on engineering design projects. Several recent discussions with engineer acquaintances made it painfully clear to the author that a significant number of them do not take us and our claims to be engineers very seriously. Among the first criticisms engineers typically levy against software developers is, “They could not even state precisely what their software would and would not do, much less under which conditions it would function correctly.” This statement contains two fundamental complaints: The software developers with whom these engineers worked were 1) unable or unwilling to commit themselves to deliver a program to meet any precise specification, i.e., to accept responsibility for delivering a precisely specified product, and 2) were not able to analyze their completed design (program) in order to verify that (and under what conditions) it would perform as specified, i.e., was free of design errors. The engineers interpreted this attitude and inability as evidence that the software developers did not understand
98
1. SYSTEMS SOFTWARE 1991; 1.5: 91-100
what they were doing, at least not in an engineering sense. We might consider their view of us as uncharitable, but they place the same expectations on their other engineering colleagues as well as on themselves. In their experience, such expectations are reasonable and are normally fulfilled. Other engineers with whom the author has discussed this subject have complained that software suppliers do not have formal procedures for releasing software products in which a technically qualified responsible officer of the company signs a corresponding certificate. Again, this is normal practice in traditional engineering. Summarizing our shortcomings in the eyes of engineers in the classical fields, we software specialists are perceived to exhibit an underdeveloped sense of responsibility for the correctness of our programs. We do not analyze our programs, using appropriate mathematical methods and models, to verify that our programs fulfill their specifications. Our attitude toward design errors is much too lax; the standards we set for ourselves are unacceptably low. This conclusion begs the following questions: Is it appropriate and feasible to specify a program as precisely as the objects and systems which classical engineers design? Does a suitable theoretical foundation exist which would enable software developers to design correct programs and verify their correctness? Are the potential consequences of errors in software serious enough to justify such efforts? If the answers to these questions are yes, then why does the current situation prevail? In Section 4 above, specifications (albeit rather simplified, highly aggregated ones) of traditional engineered objects and computer programs were compared. Clearly, they have fundamental characteristics in common. Considerable experience in designing software systems strongly suggests that software specifications as precise as those typical in other engineering fields are not only possible, but also desirable. The computing science literature contains much material on this subject and special specification languages have even been developed. A suitable theoretical foundation for verifying the correctness of programs exists. Furthermore, that theoretical foundation suggests a number of effective guidelines for designing correct programs. The technical books and articles listed in the bibliography are a small part of this literature. This material has come to the attention of only a small fraction of software developers in commercial practice and of these, only some have actually applied it to their regular work. Some report positive results, demonstrating that this theoretical foundation is applicable and of practical value. Others
R. L. Baber report negative results, which indicates that it is not especially easy to apply the theory and, perhaps, that software developers today generally lack an adequate command of the prerequisite knowledge. The consequences of errors in software can be very serious and are becoming more serious as the range of applications of computer systems in our society grows, especially in critical applications such as on-board monitoring and control in aircraft, process control in the chemical and heavy industries, nuclear reactor control, air traffic control, etc. In addition to costly consequences [2, chapter 21, human deaths have already been attributed to errors in software [20, 22, 331. As such losses increase in severity, society will put increasing pressure on software developers to bring their error rate into line with that of the classical engineering fields. Since the answers to the questions posed above are yes, why does the current situation prevail? Many of the reasons are discussed in Baber [2]. The field of software development is new-it is the first really new engineering field to emerge in some 100 years. Our theoretical foundation is comparatively new; the history of other engineering fields indicates that transferring theoretical knowledge from its source into the hands of practitioners takes considerable time [29, 31, 351. We are not yet “behind schedule.” 7. CONCLUSION: TOWARD SOFTWARE ENGINEERING Software development is “a tough engineering discipline with a strong mathematical flavour” [ 121. In the earlier sections of this article, we have seen some of the evidence suggesting that software development can and should be an engineering discipline. The history of the classical engineering disciplines and the present and recent past of the software field contain many strikingly parallel developments, patterns, and events, suggesting that software development will become an engineering discipline in the true sense of the word. The history of all classical engineering fields has confirmed Vitruvius. The software engineer, too, must thoroughly understand the theoretical foundation of his field and be able to apply it to problems arising in practice. Only when he can fulfill these requirements may he justly consider himself to be an engineer. The level of theoretical knowledge among current software practitioners must be raised. To facilitate this process, the terminology and language in which the theory is expressed should be extended to include simpler forms, conventions, and should be better e.g., notational adapted to the orientation, mentality, and needs of the engineer, as opposed to those of the theoretician or researcher.
Portrait of a Software Engineer All parties concerned must work hard to bring about a transition to true software engineering. The effort required is considerable; the rewards, great. In the final analysis, the desire and willingness of each individual software developer to make the change is the critical prerequisite for this transition. Software developers starting to learn the professional engineering approach often ask, “but can we afford the extra time-the luxury--required to take this approach?” We should be asking ourselves the questions “How much longer can we afford not to take the truly professional approach? How much longer can we afford extensive debugthe “luxury” -the time and cost-of ging, of the consequences of design errors in software delivered to our clients?” The key to the professionalization of software development is a willingness on the part of software developers to assume responsibility in some idealistic, moral and/or legal sense for the results and consequences of their work. An important prerequisite for such assumption of responsibility is a rational, scientific, technical basis for verifying a proposed design (program). Both factors are unusual exceptions rather than the rule among software developers today. By imitating the examples provided by the mature engineering fields, we can save ourselves much time and effort in our transition to an engineering discipline. The classical engineering fields have already solved most of the fundamental problems (even if in somewhat different contexts) with which we will have to come to grips in the near future. They solved those problems under circumstances at least as difficult, probably more difficult, than those we face. With hard mental work, they succeeded. So can we.
REFERENCES 1. S. Alagid and M. A. Arbib, The Design of Well-Structured and Correct Programs, Springer-Verlag, New York, Heidelberg, Berlin, 1978. 2. R. L. Baber. Software Reflected: The Socially Responsible Programming of Our Computers, North-Holland Publishing Co., Amsterdam, New York, Oxford, 1982. 3. R. L. Baber, The Spine of Software: Designing Provably Correct Software - Theory and Practice. John Wiley & Sons, Chichester, 1987. 4. R. L. Baber, “Software engineering” vs. software engineering, in, Open Channel column, IEEE Computer.
22, 81 (1989). 5. R. L. Baber, Epilogue: Future Developments, in. J. A. McDermid, ed., Software Engineer’s Reference Book, Butterworth Scientific Ltd., Guildford, 1991. 6. R. C. Backhouse, Program Construction and Verifycation, Prentice-Hall International, Englcwood Cliffs. N.J.. 1986.
J. SYSTEMS SOFTWARE 1991; 1.5: 91-100
99
7. British Computer Society, Code of Conduct, Handbook No. 5. 8. British Computer Society, Code of Practice, Handbook No. 6. 9. T. Denvir, Introduction to Discrete Mathematics for Software Engineering, Macmillan Education, Basingstoke, 1986. 10. W. Dijkhuis, Vitruvius Revisited: Architecture and Information, publication forthcoming. 11. E. W. Dijkstra, A Discipline of Programming, Pren-
tice-Hall, Inc., Englewood Cliffs, N.J., 1976. 12. E. W. Dijkstra, Selected Writings on Computing: A Personal Perspective. Springer-Verlag, New York, 1982. 13. Es. W. Dijkstra, quotation in a press report on the 17th Annual ACM Computer Science Conference, in, IEEE
Software, 6, 97 (1989). 14. R. W. Floyd, Assigning Meanings to Programs, Proceedings of the Symposium of Applied Mathematics, 19, 19-32 (1967). 15. D. Cries, The Science of Programming, SpringerVerlag, New York, Heidelberg, Berlin, 1981. 16. G. Gruman. Software safety focus of new British standard, IEEE Software, 6, 95-96 (1989). 17. C. A. R. Hoare, An Axiomatic Basis for Computer Programming, Communications of the ACM, 12, 576-580 and 583 (1969). 18. C. A. R. Hoare, Programming: Sorcery or Science?, IEEE Software, 1, 5-16 (1984). 19. C. A. R. Hoare, An Overview of Some Formal Methods for Program Design, IEEE Computer. 20, 85-91
(1987). 20. IEEE Spectrum (1987 December) Lethal dose, in, Faults isr Failures column, p. 16. 2 I. Institute of Electrical and Electronics Engineers (IEEE), Code of Ethics. 22. 13. Joyce, Software Bugs: A Matter of Life and Liability, Datamation, pp. 88-92 (May 15, 1987). 23. Ii. C. Linger, H. D. Mills, and B. I. Witt, Structured Programming: Theory and Practice, Addison-Wesley Publishing Co.. Reading, Massachusetts, 1979. 24. 3. Loeckx, and K. Sieber, The Foundations of Program Verification, B. G. Teubner. Stuttgart, and John Wiley & Sons, Chichester, 1984. 25.’ H. D. Mills, The New Math of Computer Programming, Communications of the ACM, 18, 43-48 (1975). 26. H. D. Mills, Structured Programming: Retrospect and Prospect, IEEE Software, 3, 58-66 (1986). 27. H. D. Mills. V. R. Basili, J. D. Gannon, and R. G. Hamlet, Mathematical Principles for a First Course in Software Engineering, IEEE Transactions on Software Engineering, 15, 550-559 (1989). 28. H. D. Mills, M. Dyer, and R. C. Linger, Cleanroom Software Engineering, IEEE Software. 4, 19-25 (1987). 29. P. J. Nahin, Oliver Heaviside: Sage in Solitude, IEEE Press, New York, 1988. 30. D. L. Parnas, Education for Computing Professionals,
IEEE Computer. 23, 17-22 (1990). 31. J. D. Ryder and D. G. Fink, Engineers & Electrons: A
100
J. SYSTEMS SOFTWARE 1991; 15: 91-100
Century of Electrical Progress, IEEE Press, New York, 1984. 32. R. W. Selby, V. R. Basili, and F. Baker, Cleanroom Software Development: An Empirical Evaluation, IEEE Transactions on Software Engineering, SE-13, 1027-1037 (1987). 33. M. Thomas, Should we trust computers? The BCS/UNISYS Annual Lecture 1988, British Computer Society, London, 1988.
R. L. Baber
34. Marcus Pollio Vitruvius, (ca. 25 B.C.) De architectura libri decem. Latin text and English translation by Frank @anger (1931, 1955) in Vitruvius: On Architecture. Volumes 1 and 2, The Loeb Classical Library, Heinemann, London. 35. K. L. Wildes, and N. A. Lindgren, A Century of Electrical Engineering and Computer Science at MIT, 1882-1982, MIT Press, Cambridge, Massachusetts, and London, 1985.
91
Controversy Corner It is the intention of the Journal of Systems and Software to publish, from time to time, articles cut from a different mold. This is one in that series. The object of the Controversy Corner articles is not so much to present information as to stimulate thought. Topics chosen for this coverage are not traditional formal discussions of research work, but rather are informal presentations of key issues in the systems and software world.
Portrait
of a (Software)
This series will succeed only to the extent that it
stimulates not just thought, but action. If you have a strong reaction to the article that follows, either positive or negative, write to Robert L. Glass, Editor, Journal of Systems and Software, Computing Trends, P.O. Box 213, State College, PA 16804. We will publish the best of the responses as Controversy Revisited.
Engineer
Robert L. Baber Bad homburg,
v.d,H.,
Germany
The terms “software engineering” and “software engineer” have been and are still being bandied about in ways with which many engineers in the classical engineering fields take exception. In these engineers’ view, our applying the term ~‘engineeringJ’ to software development indicates that we software developers do not understand what “engineering” means and is really all about. They suspect that we are simply trying to take advantage of the professional reputation they have earned by good, hard work, without our taking the time and trouble to acquire a comparable level of knowledge, qualification, and capability. What is engineering? What does the classical engineer perceive to be the essence of his profession? How does he view his professional work? What is his role in society and what is the nature of his relationAddress correspondence to Robert L. Baber, Landgraf Gustav Ring 5, D-6380 Bad Homburg, v.d.H.. Germany 0 Elsevier Science Publishing Co., Inc. 6% Avenue of the Americas, New York. NY 10010
ship with clients and third parties, especially with regard to the responsibilities assumed by each7 How does he prepare for his life’s work? To what extent and in what ways does he employ the knowledge acquired during his education in later professional practice? These and related questions are considered in this article. While we are particularly interested in the implications of the answers with regard to software development, our attention will be mainly directed to engineering-in the traditional sense-in general.
Engineering is born of both practice-fabrica-Ed thePractice is a mechanical facility, developed through exercise. Theory is the ability to describe and explain the designed object.
ory-ratiocinatio.
-Marcus
Vitruvius Pollio, ca. 2.5 B.C. (paraphrased translation)
OIW1212/91/$3.50
92
J. SYSTEMS SOFTWARE 1991; 15: 91-100
R. L. Baber
The programmer’s task is not just to write down a program. His main task is to give a formal proof that the program he proposes meets the equally formal functional specification. -Edsger
W. Dijkstra, 1989 A.D.
INTRODUCTION In recent years it has become increasingly popular to talk of “software engineering” and to use this term ever more ~equently in connection with various software development activities. This trend is motivated, it seems to me, by a desire to obtain the same benefits achieved in the classical engineering fields, in particular, a high ievel of design quality. To some, it might even appear that we software developers subconsciously believe (or simply hope?) that if we use the word “engineering” often enough, our software will somehow become as reliable as the designs created by classical engineers. I do not believe that this result can be achieved in this way. We will achieve a quality in our work comparable to that long since achieved in the classical engineering fields not by calling our work “engineering, ” but by really doing engineering. The difference is great, significant, and too often overlooked by software developers. What do I mean by “software engineering”? This question can be best answered by considering first and primarily the question, what do I mean by “engineering”? 1. THE ESSENCE OF ENGINEERING
What is the essence of engineering as understood by classical engineers? The application of scientific knowledge and principles to the task of designing and constructing an object, machine, or system of economic value is probably the most characteristic aspect of engineering. Especially noteworthy is that the engineer employs a scientific, theoretical foundation to verify-by systematic calculation before the object is actually built-that a proposed design will satisfy the specifications. This step gives rise to the high level of reliability to which the engineer, his clients, and society have become accustomed. It is a prerequisite for the widespread application of potentially dangerous machines, systems, etc., in society. The engineer’s goal is a practical result of economic value to his client. The engineer is concerned with the scientific theory underlying his particular field insofar as it enables him to design a more effective, efficient and/or reliable system or to reduce the time and efTort needed to design or build the system. He recognizes the value of a Vitruvian balance between theory and prac-
tice: Those whose abilities are limited to practical skills (fabrica) never achieve much of real significance. Those who, on the other hand, rely only on their knowledge of the theory (ratiocinatio) mistake the shadow of the object for the object itself. Only those who are able to apply well developed capabilities in both areas to the job to be done will accomplish it with honor. Both aspects, fabrica and ratiocinatio, are of equal-and critical-importance in professional practice [34]. Because the objects and systems designed by engineers are usually potentially dangerous-human deaths and considerable financial loss can be caused by design errors or malfunction-society permits only qualified persons to practice engineering. Furthermore, certain requirements are placed on those admitted to professional engineering practice. These restrictions and requirements vary considerably from country to country, from one field to another, and between private and corporate engineering practice. At the minimum, the prospective engineer must demonstrate that he has an adequate active command of the theoretical foundation of his field. This requirement is fulfilled by obtaining a relevant academic degree or by passing a professional examination. In some cases both are required. Often, the prospective engineer must also demonstrate a specific level of practical proficiency. A certain mathematical and theoretical knowledge-including both a common foundation and material specific to the individual technical field in question -has been found to be a prerequisite enabling the engineer to satisfy his clients’ and society’s demands for reliability and freedom from design errors. Knowledge of the underlying theory is also of direct practical value to the individual engineer; without it, he would simply not be able to compete successfully in the marketplace for engineering services. In short, society has found that it is better-in terms of overall costs incurred and benefits achieved-to make a significant investment in its engineers’ initial education. In the long run, this investment pays off well for all concerned. 2. THE ENGINEER’S RESPONSIBILITY
For several reasons the engineer takes his responsibility to his client and to potentially affected third parties seriously. First, the engineer enters into a legal contract with his client to deliver a design meeting certain specifications; if he fails to do so, i.e., if his design does not satisfy the specifications, he can be held liable for non~ifillment of contract. Second, his design must satisfy various requirements es~blished to protect the public from potential dangers arising from the construction and utilization of the object or system in question.
Portrait of a Software Engineer Third, significant shortcomings in the quality of his work can lead to the withdrawal or restriction of his professional recognition and his legal right to practice his profession. Finally, but not necessarily least important, most engineers take pride in their work and feel idealistically rewarded when they create an excellent design, especially when their peers also recognize the quality of their work. This attitude toward responsibility is reflected in the code of ethics to which most engineers are requested and many are required to subscribe. While such codes of ethics vary from country to country, from field to field, and from one professional organization to another, they do have the following important features in common: The engineer recognizes that his professional work affects the quality of life for all members of our technologically based society (not just his immediate clients). He accepts full responsibility for his actions and the results of his work, with respect to both his clients and the public. He agrees not to make exaggerated claims, not to accept assignments beyond his professional capabilities and qualifications, and to disclose any relevant limitations in his ability to perform the work in question before accepting an assignment. He agrees to maintain honest relations with all with whom he deals professionally, disclosing in advance any circumstances which could lead to a conflict of interest. He agrees to maintain and increase as required his professional knowledge and skills. In short, he agrees to take all appropriate steps to earn and ensure the continuing trust placed in him by his clients, professional colleagues, and society as a whole [7, 8, 211. The legal nature of engineering responsibility differs, certainly, between corporate and private professional practice. But even in corporate practice, fulfilling this responsibility ultimately derives from the decisions and actions of individual engineers. Under certain circumstances, at least, a professionally qualified engineer (usually an employee of the corporation in question) must personally certify that the design meets certain requirements by signing an engineering release before the corporation manufactures and supplies the system to its customers (see also Section 4 below). While legal responsibility lies largely with the corporation, some legal-and considerable professional-responsibility remains with the individual engineer. The engineer’s attitude toward his professional responsibility does, of course, give rise to a certain dichotomy. On the one hand, as stated above, the engineer takes his responsibility seriously. On the other hand, he realizes that he is a fallible human being. A certain frustration and anxiety results. Perhaps more important, however, this problem-ensuring that the
J. SYSTEMS SOFTWARE 1991: 15: 91-100
93
results (designs) are reliable despite the fact that the designers are fallible-represents a challenge which the profession and the legal and societal infrastructure accept and by and large successfully meet by a variety of means. The scientific theory underlying the field, formal reviews of the design by official certification authorities, other organizational checks, etc., play important roles in this respect. The engineer, recognizing his own fallibility, does not actually expect to get all aspects of all designs in his entire career right, but he does expect and try hard to get each individual one right. Just because one cannot expect to actually reach a goal does not mean that one should not bother to try to get as close as possible to it. And, of course, errors with particularly serious consequences must be avoided by taking special and extra precautionary steps. Expressed more mathematically, the engineer realizes that while an error rate identical to zero is not achievable, the greatest lower bound of the error rate is equal to zero. It follows that one can achieve an error rate arbitrarily close to zero. So the engineer tries, aiming for zero. The professional engineer’s attitude toward his responsibility and the theoretical and scientific foundation for his work are mutually interdependent. The scientific basis for his work enables the engineer in principle to verify analytically and in a mechanistic way that his design will satisfy the specifications. This, in turn, (again, in principle) eliminates the personal risk associated with the acceptance of responsibility for the correctness of his design. Thus, his command of the relevant scientific foundation and his ability to apply it to practical design problems enable the engineer to accept responsibility for his design without assuming undue personal risk. On the other hand, society’s need to reduce the risk of damage to property and loss of life due to faulty designs is a primary reason for holding the engineer responsible for the quality of his designs, which in turn gives rise to the need to understand thoroughly the technical and scientific nature of the design work being undertaken. In short, the scientific foundation for his work enables the engineer in principle to get his designs right and to accept responsibility therefor. Some room for error still exists, of course, arising from carelessness, negligence, or inadequate knowledge, e.g., of recent technological developments. To a certain extent, organizing his calculations and work appropriately can help to reduce the likelihood of such errors, but in the final analysis some chance for error remains which only the engineer’s determined effort-and reviews conducted by others-can reduce further.
94
R. L. Baber
J. SYSTEMS SOFTWARE 1991: 15: 91-100
3. THE EDUCATION
OF THE ENGINEER
The engineer prepares for his life’s work by completing a formal tertiary academic education of several years duration. During this time he learns the theoretical and scientific foundation of his field so thoroughly and uses it so extensively to solve realistic exercises that its application becomes almost a reflex action. (For example, an electrical engineering graduate who has subsequently pursued a career in another field can typically interpret and explain Maxwell’s equations even though he has not used them in decades.) This type of knowledge is particularly important, for it is not subject to change and will remain valid and applicable throughout the engineer’s career. In laboratory work, the student engineer also acquires a sense of practical reality. In particular, he becomes familiar with practical limitations deriving from the current state of the technology. While such an appreciation of practical reality and limitations is important, this knowledge is subject to change and is, therefore, of less ~ndament~ importance. In fact, one of the tasks of many engineers is to reduce such limitations and push the forefront of the practically attainable (the “state of the art”) into previously unattainable regions. In the fields of aeronautical and electrical engineering, for example, rather astounding advances have been made in the past several decades. Engineers in these fields are now routinely designing devices and systems which were well beyond the limits of technology when they were students. When the engineering student completes his academic studies, he has acquired most of the basic scientific knowledge he will need during his career. Just as important, he has learned how to learn the additional material he will find that he needs later. While he will have acquired some practical experience, it is primarily in this area that his preparation for professional practice is incomplete. In particular, he will have dealt mainly with small systems or subsystems and will have had no or only superficial contact with really large engineering design projects, e.g., requiring many years of engineering effort to complete. Experience in the classical engineering fields in the century or so of their existence strongly suggests that it is more efficient and effective to acquire a thorough knowledge of the theoretical foundation first and then to obtain practical experience. The young engineer with a good knowledge of the theory will benefit much more from, say, a year of experience on the job than would someone without the theoretical knowledge. His theoretical knowledge helps him in drawing conclusions from his observations on the job and sharpens his perception, often suggesting what to look for. In con-
trast, practical experience helps less in learning the theory, with the possible exception of motivational effects. (Sanding several months on the job doing a task the hard way and then subsequently learning some theoretical material which reduces the task to a severalday job is a sobering experience which tends to motivate the student to acquire more fundamental ~owledge.) After completing his formal academic studies, the new engineer must acquire a few years experience before he can justly claim full professional status. Particularly in this regard can one observe considerable differences between countries, technical fields, professional organizations, etc., but in most cases a certain length of certified experience is required before an engineering society will promote a member to full or advanced professional status. It is usually considered irn~~nt that the new engineer’s initial experience be planned to include both a certain breadth of exposure as well as significant depth in selected areas. Furthermore, he should be supervised and guided by an experienced engineer who acts as a sort of informal tutor. The pedagogical goal is to structure this initial experience so that the new engineer benefits as much from it and increases his abilities and qualifications as rapidly as possible. In order to achieve this goal, the work assigned should have a truly professional content and make a significant contribution to the larger projects of which it is a part. Even after attaining full professional status, the engineer’s education is still not complete-it is never really complete. The successful engineer who is interested in his work never stops learning. This is, in fact, one of the cha~cteristics of a professional field which distinguishes it from a craft or non-professional technical occupation. The true professional continues to advance the state of the “art” and his own qualifications. In his continuing education, the professional learns not only new facts or technical skills, e.g., how to use a computerized drawing system (the architect), how to write in’ a new programming language (the software engineer), how to use an automated blood pressure meter (the physician), etc., but, more important, he tries to increase his ~ndamen~ u~de~~tffndjng of the phenomena of interest and concern in his field. 4. ENGINEERING DESIGN The engineering design task, in the narrow sense, begins with an external specification of the object to be designed and ends with a suitably complete description of its internal structure-the internal specification. In the broader sense, engineering design work includes defining the external specification. Because the external s~cification embodies the technical essence of the
Portrait of a Software Engineer agreement (contract) between the design engineer and his client, an appropriate dialogue and negotiation between the two are an important part of this preliminary phase of the design work. The engineering design task can be thought of as a creative process translating one formal description (mathematical model) of the object to another formal description, the latter being much more detailed and reflecting the internal structure. The design engineer has two obligations to fulfill: 1) to deliver the design (the internal s~ci~cation) and 2) to demonstrate analytically that his internal specification fulfills, i.e., correctly implements, the given external specification. The latter step-convincing himself and other engineers by technical and scientific calculations and arguments, before actually building the object, that the internal specification implements the external specification-is in many engineering fields a prerequisite for obtaining a building permit or an operating license. In all classical engineering fields, both of the above tasks are accepted as the engineer’s obligations. As Prof. Dijkstra clearly stated {see the quo~tion at the ~ginning of this article), the software developer has the same two obligations FI31. Correspondingly, the engineering design task consists of two phases. The first phase, creating the internal specification, is primarily of a creative nature. Scientific and technical considerations play a role, to be sure, and can provide useful guidelines, but imagination, innovation, new ideas, etc., are important, appropriate, and desired. In this creative, non-mechanistic phase, the engineer makes many design decisions, finally selecting one of the many possible designs which would fulfill the external s~~ifi~ation. The second phase, on the other hand, consists of a predominantly determinate and mechanistic analysis, structured in a standard way and following established rules and procedures. The goal of the second phase is to verify, generally by appropriate calculations, that the design satisfies the requirements set down in the external specification. Major improvements and technological breakthroughs derive from innovation in the creative phase. The reliability characteristic of professional engineering derives from proficiency and skill in the application of the theoretical and scientific foundation mentioned earlier to the task of formally verifying that the design (internal specification) fulfills the external specification. The external specification deals with 1) those externally observable characteristics and properties of the object to be designed which are of im~~nce or concern to the user (the “performance” of the system) and 2) those environmental conditions which may affect the object and its ability to deliver the desired perfor-
J. SYSTEMS SOFTWARE 1991; 15: 91-100
95
mance. The environmental conditions include, but are not limited to, those under the control of the users. In practice, an external specification is never an absolute statement, e.g., “the bridge will withstand the applied Ioad,” but is always a conditions statement, e.g., “if the total load does not exceed X tons and if no axle load exceeds Y tons and if no earthquake exceeding scale 2 occurs in the immediate vicinity and if the ambient temperature is between A and B degrees centigrade and if the wind speed does not exceed C km/hr and if . . . , then the bridge will withs~nd the applied load.” The conditions are important and often extensive, even more extensive than the statements about the performance characteristics. They are an integral part of the external specification. Overlooking some of these conditions can easily lead to an unsatisfactory design. The final specification often explicitly includes conditions about internal components (it always implicitly presupposes them). Obviously, the design engineer cannot be held responsible for everything and all eventualities. The conditions in the external specification serve to define the boundaries between the res~nsibilities of the engineer, his client, and third parties, expiicitly taking into account relevant factors not under the control of anyone (“force majeure” and “acts of God” in legal terminology). The above comments apply not only to the classical engin~ring fields, but are equally valid in the specific context of software. The external specification of a program segment or entire program also typically takes on the form of a conditional statement: If the values of the program variables (and, where applicable, input data and elements of data files) fulfill a certain condition (called the precondition) before the program is executed, then the values of the program variables, output data, and elements of data files afterward will satisfy another condition (the postcondition). Not infrequently, the external specification consists of a hierarchy of such conditions statements, e.g., in the following simplified part of a specification for an aircraft: If all four engines are functioning normally, i.e. deliver the specified thrust, then the aircraft will be able to reach and maintain level flight at any altitude up to 12000 m and a speed of at least 900 km/hr. and If at least three engines are functioning normally, then the aircraft will be able to reach and maintain level flight at any altitude up to 8000 m and a speed of at least 5.50 km/hr. and If at least two engines are functioning normally, then the
96
R. L. Baber
J. SYSTEMS SOFTWARE 1991; 1.5: 91-100
aircraft will be able to maintain stable flight at any altitude
up to 2000 m. Note that a certain degradation of performance is specifically provided for in the specification; it is not a random result of the design process. In software development, quite comparable situations arise, especially with regard to “correct” and “incorrect” inputs entered by the user, for example: If the data entered by the user is “correct” (which must be unambiguouslydefined in another part of the specification), then the system will print out report X (also described elsewhere in the specification). and
If the data entered by the user is “incorrect”,
then the system will display an error message as specified in table X (part of the specification).
Certain data may represent an error condition in terms of the application and the user, but to the designer “incorrect” input data are not “wrong” or “erroneous” in any meaningful sense. They, too, must be processed in a very specific way with a result as stipulated in the specification. The internal specification states what components are to make up the object being designed and how those components are to be interconnected. It describes the interfaces between the components and, in particular, the characteristics of the components upon which the correctness of the overall design of the object depends. These characteristics are, in turn, external specifications of the individual components. In the case of a design of a bridge, for example, the internal specification will consist of a plan for connecting the individual girders in a particular way together with statements about the dimensions, strengths, etc., of the individual girders. The engineer will also include a calculation showing that the requirements laid down in the external specification will be satisfied by his design, in particular, that the bridge will support itself and the intended load without collapsing (under the conditions assumed and explicitly stated). Such calculations are based on the scientific theory underlying the field in question-here, statics (a special case of Newton’s laws). In the case of a computer program, the internal specification will consist of its code and definitions of the interfaces between it and the subprograms it calls (pre- and postconditions and complete lists of the variables modified by the subprograms). Each description of an interface is, in effect, an external specification of the called subprogram. The software engineer who views his task as Prof. Dijkstra defined it [13] will give a logical proof that the program’s external specification
will be met, assuming of course that the called subprograms satisfy their interface specifications, that the interpreter or compiler fulfills its specifications, that the hardware functions as assumed, etc. In engineering design projects, a responsible engineer is typically expected to sign an official release of the design when it is completed. Often only an engineer possessing certain legally recognized qualifications is authorized to sign such a release. By signing the release he formally accepts professional responsibility for the correctness, safety, suitability, etc., of the design. In a certain sense he stakes his professional reputation on the design and its conformity with the specifications. This formal step is typically of legal significance. Signing a formal release of the design can have other, informal, even personal significance to the engineer. At least some engineers experience a sense of accomplishment and a feeling of pride associated with assuming formal responsibility for the design. This act symbolizes the considerable effort leading to a successful result of which the entire design team can be proud. It involves a certain assumption of risk, to be sure, but that risk is estimable and in a certain general sense limited (and therefore acceptable) because the engineer knows why and to what extent he can have confidence in the design. The scientific and theoretical foundation for his work and the mathematical models he uses enable him to determine analytically under what conditions the design will-and will not-perform as required. In summary, perhaps the two most fundamentally important prerequisites for professional engineering practice are 1) the theoretical and scientific foundation which the engineer thoroughly understands and continually applies in his work and 2) a highly developed sense of responsibility toward his clients and the public. The first prerequisite enables the engineer to assume and discharge the obligations deriving from the second. In this regard, engineering is directly comparable to other professions such as medicine and law.
5. THE ENGINEER’S PROFESSIONAL ENVIRONMENT The engineer is embedded in an environment which influences, supports and restricts his professional activities. The most important elements of his professional (as opposed to commercial) environment are the academic institutions which educate engineers (see Section 3), the legal structure regulating professional practice, and the professional associations. These three elements are typically formally interrelated. Engineers working as employees are also, of course, embedded in a corporate environment reflecting both commercial and pro-
Portrait of a Software Engineer
fessional interests and concerns. Typically, the professional aspects of the corporate environment consist of norms set by the external professional structure which have been selected, specialized, and adapted to the corporation’s particular business. We will, therefore, restrict our attention here to those external professional influences. Particularly in the area of the professional associations can one find significant differences between the classical engineering fields on the one hand and software development on the other. A professional engineering society typically restricts full membership to those who fulfill certain formal requirements. Interest in the field is not sufficient. The minimum requirement for full membership is a relevant academic degree or its equivalent, e.g., passing a special examination. Many such associations require that applicants formally subscribe to a code of ethics and professional conduct. Furthermore, engineering societies in many countries have several grades of membership. Only after acquiring a certain amount of practical experience (certified by other engineers with regard to quantity and quality) is one eligible for promotion to a higher grade of membership. Professional engineering societies typically have procedures for reprimanding members who practice in a manner judged to be incompetent, inadequate, questionable, or unethical or which reflects negatively on the profession. In extreme cases, they may be expelled from membership. In some countries, such action effectively limits the professional activities in which the engineer affected may subsequently legally engage. The use of certain forms of engineering titles is restricted by law and unauthorized persons using them are subject to prosecution. For example, the title “Professional Engineer” (P.E.) is protected in the U.S.A.; “Chartered Engineer” (C.Eng.) in the United Kingdom; and “Ingenieur” (engineer) in the Federal Republic of Germany. Most associations of computing specialists have no formal prerequisites for membership. Anyone who is interested in the field and who is willing to pay the membership fee may join. While some of these associations may suggest or recommend certain codes of ethics and conduct, they cannot effectively enforce them. Associations of this type differ from the traditional professional societies in fundamental ways. A few associations of computing specialists exist which represent intermediate organizational forms. Some engineering societies have subgroups for members with a particular interest in computing, e.g., the Computer Society of the Institute of Electrical and Electronics Engineers (IEEE) in the U.S.A. Such subgroups of engineering societies may or may not admit
J. SYSTEMS SOFTWARE 1991; 15: 91-100
97
as members persons not qualified for full membership in the parent body. The British Computer Society, originally a non-professional computing association, was an example of another intermediate organizational form until it was admitted to the Engineering Council as a professional engineering society in 1990. Every association’s rules and regulations regarding admission to membership, maintenance of membership, promotion to higher grades, etc., reflect its members’ view of their own role, their attitude toward their work, and their responsibility to clients, other practitioners and third parties. They also reflect how seriously the members take their work and how proud they are of the results of their work. If the field of software development is to become a full-fledged engineering discipline, its professional associations must make corresponding adjustments in their structure, rules, regulations, etc. The path which this development will take is currently unclear. The subgroups of existing professional engineering societies could assume this role for software developers (there are some signs of this occurring in the U.S. A.). Or existing associations of computing specialists could reorient themselves to satisfy the needs of professional computing and software engineers (as in the U.K.). Alternatively, new professional engineering associations could be formed. 6. THE SOFTWARE DEVELOPER: AN ENGINEER? To what extent does the above portrait of an engineer apply to us software developers today? In what ways do we fall short of being engineers? Perhaps most telling is the view engineers in the classical fields have of software developers with whom they have worked jointly on engineering design projects. Several recent discussions with engineer acquaintances made it painfully clear to the author that a significant number of them do not take us and our claims to be engineers very seriously. Among the first criticisms engineers typically levy against software developers is, “They could not even state precisely what their software would and would not do, much less under which conditions it would function correctly.” This statement contains two fundamental complaints: The software developers with whom these engineers worked were 1) unable or unwilling to commit themselves to deliver a program to meet any precise specification, i.e., to accept responsibility for delivering a precisely specified product, and 2) were not able to analyze their completed design (program) in order to verify that (and under what conditions) it would perform as specified, i.e., was free of design errors. The engineers interpreted this attitude and inability as evidence that the software developers did not understand
98
1. SYSTEMS SOFTWARE 1991; 1.5: 91-100
what they were doing, at least not in an engineering sense. We might consider their view of us as uncharitable, but they place the same expectations on their other engineering colleagues as well as on themselves. In their experience, such expectations are reasonable and are normally fulfilled. Other engineers with whom the author has discussed this subject have complained that software suppliers do not have formal procedures for releasing software products in which a technically qualified responsible officer of the company signs a corresponding certificate. Again, this is normal practice in traditional engineering. Summarizing our shortcomings in the eyes of engineers in the classical fields, we software specialists are perceived to exhibit an underdeveloped sense of responsibility for the correctness of our programs. We do not analyze our programs, using appropriate mathematical methods and models, to verify that our programs fulfill their specifications. Our attitude toward design errors is much too lax; the standards we set for ourselves are unacceptably low. This conclusion begs the following questions: Is it appropriate and feasible to specify a program as precisely as the objects and systems which classical engineers design? Does a suitable theoretical foundation exist which would enable software developers to design correct programs and verify their correctness? Are the potential consequences of errors in software serious enough to justify such efforts? If the answers to these questions are yes, then why does the current situation prevail? In Section 4 above, specifications (albeit rather simplified, highly aggregated ones) of traditional engineered objects and computer programs were compared. Clearly, they have fundamental characteristics in common. Considerable experience in designing software systems strongly suggests that software specifications as precise as those typical in other engineering fields are not only possible, but also desirable. The computing science literature contains much material on this subject and special specification languages have even been developed. A suitable theoretical foundation for verifying the correctness of programs exists. Furthermore, that theoretical foundation suggests a number of effective guidelines for designing correct programs. The technical books and articles listed in the bibliography are a small part of this literature. This material has come to the attention of only a small fraction of software developers in commercial practice and of these, only some have actually applied it to their regular work. Some report positive results, demonstrating that this theoretical foundation is applicable and of practical value. Others
R. L. Baber report negative results, which indicates that it is not especially easy to apply the theory and, perhaps, that software developers today generally lack an adequate command of the prerequisite knowledge. The consequences of errors in software can be very serious and are becoming more serious as the range of applications of computer systems in our society grows, especially in critical applications such as on-board monitoring and control in aircraft, process control in the chemical and heavy industries, nuclear reactor control, air traffic control, etc. In addition to costly consequences [2, chapter 21, human deaths have already been attributed to errors in software [20, 22, 331. As such losses increase in severity, society will put increasing pressure on software developers to bring their error rate into line with that of the classical engineering fields. Since the answers to the questions posed above are yes, why does the current situation prevail? Many of the reasons are discussed in Baber [2]. The field of software development is new-it is the first really new engineering field to emerge in some 100 years. Our theoretical foundation is comparatively new; the history of other engineering fields indicates that transferring theoretical knowledge from its source into the hands of practitioners takes considerable time [29, 31, 351. We are not yet “behind schedule.” 7. CONCLUSION: TOWARD SOFTWARE ENGINEERING Software development is “a tough engineering discipline with a strong mathematical flavour” [ 121. In the earlier sections of this article, we have seen some of the evidence suggesting that software development can and should be an engineering discipline. The history of the classical engineering disciplines and the present and recent past of the software field contain many strikingly parallel developments, patterns, and events, suggesting that software development will become an engineering discipline in the true sense of the word. The history of all classical engineering fields has confirmed Vitruvius. The software engineer, too, must thoroughly understand the theoretical foundation of his field and be able to apply it to problems arising in practice. Only when he can fulfill these requirements may he justly consider himself to be an engineer. The level of theoretical knowledge among current software practitioners must be raised. To facilitate this process, the terminology and language in which the theory is expressed should be extended to include simpler forms, conventions, and should be better e.g., notational adapted to the orientation, mentality, and needs of the engineer, as opposed to those of the theoretician or researcher.
Portrait of a Software Engineer All parties concerned must work hard to bring about a transition to true software engineering. The effort required is considerable; the rewards, great. In the final analysis, the desire and willingness of each individual software developer to make the change is the critical prerequisite for this transition. Software developers starting to learn the professional engineering approach often ask, “but can we afford the extra time-the luxury--required to take this approach?” We should be asking ourselves the questions “How much longer can we afford not to take the truly professional approach? How much longer can we afford extensive debugthe “luxury” -the time and cost-of ging, of the consequences of design errors in software delivered to our clients?” The key to the professionalization of software development is a willingness on the part of software developers to assume responsibility in some idealistic, moral and/or legal sense for the results and consequences of their work. An important prerequisite for such assumption of responsibility is a rational, scientific, technical basis for verifying a proposed design (program). Both factors are unusual exceptions rather than the rule among software developers today. By imitating the examples provided by the mature engineering fields, we can save ourselves much time and effort in our transition to an engineering discipline. The classical engineering fields have already solved most of the fundamental problems (even if in somewhat different contexts) with which we will have to come to grips in the near future. They solved those problems under circumstances at least as difficult, probably more difficult, than those we face. With hard mental work, they succeeded. So can we.
REFERENCES 1. S. Alagid and M. A. Arbib, The Design of Well-Structured and Correct Programs, Springer-Verlag, New York, Heidelberg, Berlin, 1978. 2. R. L. Baber. Software Reflected: The Socially Responsible Programming of Our Computers, North-Holland Publishing Co., Amsterdam, New York, Oxford, 1982. 3. R. L. Baber, The Spine of Software: Designing Provably Correct Software - Theory and Practice. John Wiley & Sons, Chichester, 1987. 4. R. L. Baber, “Software engineering” vs. software engineering, in, Open Channel column, IEEE Computer.
22, 81 (1989). 5. R. L. Baber, Epilogue: Future Developments, in. J. A. McDermid, ed., Software Engineer’s Reference Book, Butterworth Scientific Ltd., Guildford, 1991. 6. R. C. Backhouse, Program Construction and Verifycation, Prentice-Hall International, Englcwood Cliffs. N.J.. 1986.
J. SYSTEMS SOFTWARE 1991; 1.5: 91-100
99
7. British Computer Society, Code of Conduct, Handbook No. 5. 8. British Computer Society, Code of Practice, Handbook No. 6. 9. T. Denvir, Introduction to Discrete Mathematics for Software Engineering, Macmillan Education, Basingstoke, 1986. 10. W. Dijkhuis, Vitruvius Revisited: Architecture and Information, publication forthcoming. 11. E. W. Dijkstra, A Discipline of Programming, Pren-
tice-Hall, Inc., Englewood Cliffs, N.J., 1976. 12. E. W. Dijkstra, Selected Writings on Computing: A Personal Perspective. Springer-Verlag, New York, 1982. 13. Es. W. Dijkstra, quotation in a press report on the 17th Annual ACM Computer Science Conference, in, IEEE
Software, 6, 97 (1989). 14. R. W. Floyd, Assigning Meanings to Programs, Proceedings of the Symposium of Applied Mathematics, 19, 19-32 (1967). 15. D. Cries, The Science of Programming, SpringerVerlag, New York, Heidelberg, Berlin, 1981. 16. G. Gruman. Software safety focus of new British standard, IEEE Software, 6, 95-96 (1989). 17. C. A. R. Hoare, An Axiomatic Basis for Computer Programming, Communications of the ACM, 12, 576-580 and 583 (1969). 18. C. A. R. Hoare, Programming: Sorcery or Science?, IEEE Software, 1, 5-16 (1984). 19. C. A. R. Hoare, An Overview of Some Formal Methods for Program Design, IEEE Computer. 20, 85-91
(1987). 20. IEEE Spectrum (1987 December) Lethal dose, in, Faults isr Failures column, p. 16. 2 I. Institute of Electrical and Electronics Engineers (IEEE), Code of Ethics. 22. 13. Joyce, Software Bugs: A Matter of Life and Liability, Datamation, pp. 88-92 (May 15, 1987). 23. Ii. C. Linger, H. D. Mills, and B. I. Witt, Structured Programming: Theory and Practice, Addison-Wesley Publishing Co.. Reading, Massachusetts, 1979. 24. 3. Loeckx, and K. Sieber, The Foundations of Program Verification, B. G. Teubner. Stuttgart, and John Wiley & Sons, Chichester, 1984. 25.’ H. D. Mills, The New Math of Computer Programming, Communications of the ACM, 18, 43-48 (1975). 26. H. D. Mills, Structured Programming: Retrospect and Prospect, IEEE Software, 3, 58-66 (1986). 27. H. D. Mills. V. R. Basili, J. D. Gannon, and R. G. Hamlet, Mathematical Principles for a First Course in Software Engineering, IEEE Transactions on Software Engineering, 15, 550-559 (1989). 28. H. D. Mills, M. Dyer, and R. C. Linger, Cleanroom Software Engineering, IEEE Software. 4, 19-25 (1987). 29. P. J. Nahin, Oliver Heaviside: Sage in Solitude, IEEE Press, New York, 1988. 30. D. L. Parnas, Education for Computing Professionals,
IEEE Computer. 23, 17-22 (1990). 31. J. D. Ryder and D. G. Fink, Engineers & Electrons: A
100
J. SYSTEMS SOFTWARE 1991; 15: 91-100
Century of Electrical Progress, IEEE Press, New York, 1984. 32. R. W. Selby, V. R. Basili, and F. Baker, Cleanroom Software Development: An Empirical Evaluation, IEEE Transactions on Software Engineering, SE-13, 1027-1037 (1987). 33. M. Thomas, Should we trust computers? The BCS/UNISYS Annual Lecture 1988, British Computer Society, London, 1988.
R. L. Baber
34. Marcus Pollio Vitruvius, (ca. 25 B.C.) De architectura libri decem. Latin text and English translation by Frank @anger (1931, 1955) in Vitruvius: On Architecture. Volumes 1 and 2, The Loeb Classical Library, Heinemann, London. 35. K. L. Wildes, and N. A. Lindgren, A Century of Electrical Engineering and Computer Science at MIT, 1882-1982, MIT Press, Cambridge, Massachusetts, and London, 1985.