1. Introduction

The authors, along with Dr. Simon Rogerson, formed the executive committee of the IEEE-CS/ACM joint task force on Software Engineering Ethics and Professional Practices (SEEPP). This task force produced the Software Engineering Code of Ethics and Professional Practice (Gotterbarn et al., 1997). This code was adopted by both the ACM and the IEEE Computer Society, and is distinctive in part because it was developed for a profession, rather than for a particular organization or society. The ACM and the IEEE have recently sponsored the Software Engineering Professionalism and Ethics Project to encourage study, understanding, and revisions of the Code.

In this paper we will describe some themes that proved important in the design of the code, and some of the practical and philosophical challenges encountered during the implementation of that design. We will also point out how the maturation of the discipline of software engineering affects the code.

2. Design of the Code

Even before the SEEPP code was adopted, computer professionals had a variety of codes to choose from. The ACM, the IEEE CS, AITP, and others all have professional codes. However, SEEPP was charged with developing a code with several unique characteristics:

• The SEEPP code was to help define the profession of "software engineer" as an entity distinct from other computer professionals.
• SEEPP planned, from the beginning, to have a code adopted by both the ACM and the IEEE-CS. If the profession was to be significantly influenced by an ethics code, it was important to have support from both organizations.
• SEEPP was to include managerial aspects as well as technical aspects of development in the same code.
• SEEPP was concerned with reflecting the international scope of the software engineering profession.
• The code was to inform software engineers at multiple levels: the code should be inspirational, but also instructional. It was designed to establish and sustain a set of values for the profession, and also to help practitioners identify practical ethical issues in their work lives.

In order to approach these ambitious goals, SEEPP attempted to include a diversity of people in the effort. The SEEPP effort determined that the profession of software engineers was, at its heart, closely allied with other professional engineers, and the code reflects that emphasis: it focuses on practical matters of development more than theoretical aspects, and includes much thought about customers, management, and design tradeoffs.

Early in the development of the code, SEEPP solicited, largely via email, suggestions and comments from the worldwide members of ACM and IEEE-CS. Brain storming, early drafts, and advice occurred with some frequency about many topics. Members of the task force formulated imperatives which were refined over the long history of the code's development.

3. Development of the Code

The SEEPP task force is multinational in citizenship and in membership in professional computing organizations. After extensive study of several codes of ethics of computing societies, engineering societies and other professions, SEEPP selected imperatives for the draft Code. SEEPP also contributed new imperatives related to their knowledge of software engineering and based on external reviewer's suggestions.

The draft Code was reviewed by members of several professional computing societies and went through several revisions. Version 3 appeared with a turnaround ballot in IEEE Computer and Communications of the ACM, the flagship journals of the IEEE Computer Society and the ACM respectively. In analyzing the ballots, we found that most clauses in the code received better than a 90% approval rating. Contributed comments led to the development of Version 4 which SEEPP submitted for peer review using the IEEE's formal technical standard review process. The Code passed this process, and comments from that review were used to develop the Version 5.2 of the Code. (The code is available on the Web at http://www.cs.etsu.edu/seeri/secode.htm.) Version 5.2 was approved by the ACM in November of 1998 and by the IEEE-CS in December of 1998.

The SEEPP executive committee was impressed by the consistently high level of agreement about the behavior expected of a professional software engineer. There is general agreement about our obligations as software engineers. However, it was clear from the comments that some software engineers were being pressured by various forces to not always fulfill these obligations.

Several aspects of the Code development were more difficult than anticipated. Working cooperatively with two large, powerful organizations was at times cumbersome. Forging agreements (not consensus) among philosophers, practitioners, and computer scientists was never easy. There were tradeoffs made between making an intellectually "perfect" code and developing a document that was acceptable to a large majority of participants. Some of these tradeoffs were matters of style and wording; a few were more substantial.

One example of tradeoffs was the eventual structure of the Code itself. Some SEEPP members wanted a concise code. Such a code would be relatively high level and inspirational. Other members wanted a more detailed document, a document with enough detail to give practitioners sound direction in making technical decisions ethically. The Code is now presented in two versions: the short version, fulfilling the desire for conciseness; and the long version, with more details. Along with the Preamble, the versions complement each other, following the same major points at two levels of abstraction.

A few aspects of the Code's development (a precious few, actually) were actually easier than we expected. We anticipated more resistance than surfaced to the clauses about whistleblowing. Once the Code was presented in the Communications and Computer, we were pleasantly surprised at the generally positive response. The SEEPP deliberations were far more contentious than most of the comments from ACM and IEEE-CS members. We have also been gratified at the level of interest from the business sector. Several organizations have already adopted the Code or some adaptation of the Code.

4. Interactions between Technical Standards and Ethical Standards

At least in part because SEEPP followed the protocols for approving technical standards, we were particularly sensitive to the relationship between ethical standards and technical standards in software engineering. SE is young and has been moving from no standards ("Just get it done and out the door!") toward the knowledge and skills required to develop complex safety critical systems (Knight and Littlewood, 1994). There are now several kinds of software engineering "standards" that compete. The situation is evolving rapidly. The discipline is maturing, but not mature.

The SEEPP executive committee resisted the notion of putting specific software standards in the Code. Since techniques are constantly improving, and since the approval process of the Code is at least a year in length, then if we included specific standards in the Code, the Code would likely be obsolete the moment it was approved. Furthermore, we thought that including particular standards and excluding others in the Code could lead to a premature "blessing" of some standards, encouraging a harmful retardation of the development of better software development techniques.

Instead of canonizing particular standards that existed when the Code was written, the Code makes reference to "currently accepted standards," in hopes that as standards are increasingly well defined and accepted, the Code could encourage their use. Some critics of the Code find this unacceptable, preferring specific standards. They view the Code as an opportunity to rally the profession around more stringent standards for development. The SEEPP executive committee is sympathetic to this sentiment, but decided that the discipline has not matured to the point where it could develop consensus around a particular set of software development standards.

Historically, there has been a transition away from regulatory codes designed to penalize divergent behavior and internal dissent, toward codes which are more normative. Such normative codes are only a partial representation of the ethical standards of the profession's members. These more normative codes are not considered as exhaustive lists of rights or wrongs; nor are they considered algorithms to decide what is wrong. The use of normative codes requires moral judgement on the part of professional. A sense of moral responsibility is needed for the application of a code to concrete situations.

The Code aids decision making by overcoming two difficulties with other codes. First, most codes of ethics provide a finite list of principles which are often presented as a complete list and the reader presumes that only things in the list should be of ethical concern for the professional. Second, many codes provide no guidance for situations where rules, having equal priority, appear to conflict. This equal priority leaves the ethical decision maker confused. The Software Engineering Code address both of these limitations.

The Code acknowledges its incompleteness as a means of limiting mindless checkbox ethics. The Code does not leave the reader without support but it provides some suggestions about how to make decisions:

" These Principles should influence software engineers to consider broadly who is affected by their work; to examine if they and their colleagues are treating other human beings with due respect; to consider how the public, if reasonably well informed, would view their decisions; to analyze how the least empowered will be affected by their decisions; and to consider whether their acts would be judged worthy of the ideal professional working as a software engineer. In all these judgments concern for the health, safety and welfare of the public is primary; that is, the "Public Interest" is central to this Code."

The first principle in the Code asks the developer to consider all stakeholders, not just the software engineer's employer or client. The second principle Ð due respect Ð requires a protection of human values. This section also addresses the question of an equal priority of the rules by stating that in all decisions the public interest is the primary concern.

To reinforce the priority of public well being, the Code asserts the priority of concern for the public over loyalty to the employer or profession. It is a professional's obligation to take positive action to address violations of the Code.

Codes serve to educate, both prospective and existing members of a profession about the shared commitment of the members of a profession to undertake a certain quality work and the responsibility for the well being of the customer and user of the developed product. Ethics codes also serve to educate managers of the groups of professionals about expected behavior. A manager's expectations will have an effect on what is asked of a professional. Directly and indirectly codes educate management about their responsibility for the effects and impacts of the products developed.

Codes also serve as indirectly educating the public at large about what the professionals consider to be a minimal acceptable practice in that field, even if practiced by a non-professional. Thus the code can be a catalyst to simultaneously raising the internal expectations of a profession and the expectations of the society at large.

As we have seen, the Code encourages the professional to do positive actions. The Code also the professional resist pressures to act unethically. The professional can appeal to the imperatives of the Code to indicate ethically accepted practice. The official weight of the approving organizations then is brought to bear against pressure to act unethically. The effectiveness of such appeals is related to the type of sanctions levied against violations of the code.

5. Summary

SEEPP does not consider the joint ACM/IEEE-CS Code to be a final product. It is a work in progress, a method for education, inspiration, and continued study and debate. We have seen it provoke serious discussions about the discipline of software engineering, its responsibilities, and its future. We hope to continue to be a part of that future as we improve ourselves and our profession.

References

D. Gotterbarn, K. Miller, and S. Rogerson. Software engineering code of ethics: IEEE-CS/ACM Joint Task Force on Software Engineering and Professional Practices. Appearing both in IEEE Computer (October 1997), 88-92; and in Communications of the ACM (November 1997), 110-118.

J. C. Knight and B. Littlewood. Critical task of writing dependable software. IEEE Software 11(1) (January, 1994)16-20.

© 1999 Dr. Donald Gotterbarn and Dr. Keith Miller. Published with permission of the copyright holder.