I have been involved in writing two codes of ethics. One was the "Code of Ethics and Professional Conduct of the Association for Computing Machinery" (ACM code). Work began on that code early in 1991, with adoption late in 1992. The other code was the "Software Engineer's Code of Ethics and Professional Practice" (SE code). Work on that code began in 1993, with adoption in 1999. The two codes were as different as the time between conception and adoption. The process of writing them was also different. Let me begin with the codes themselves.

Two Formats
The ACM code, governing only ACM members (whether full members, associates, or students), consists of a preamble and twenty-four "Imperatives" divided into four "sections". The first section consists of eight "General Moral Imperatives" (for example, 1.1 Contribute to society and human well-being "); the second, of eight more specific "Professional Imperatives" ("2.1 Strive to achieve the highest quality, effectiveness, and dignity in both the process and products of professional work"); the third, of six special responsibilities of computer professionals in leadership roles ("3.1 Articulate social responsibilities of members of an organizational unit and encourage full acceptance of those responsibilities"); and the last, of two imperatives concerning the code's realization in practice ("4.1 Uphold and promote the principles of this Code"). The preamble explains how to use the code. Under each imperative, there are "Guidelines" designed to help with interpreting the imperative. The Guidelines are more like explanations of the imperatives than like additional rules.

The SE code was the work of the world's two largest software -related societies, the ACM and the Computer Society of the Institute of Electrical and Electronic Engineers (IEEE CS), but applies to all software engineers, not just to the minority who are members of ACM or IEEE CS. That is one difference between the two codes.

Another difference is in organization. The SE code begins with a "Short Version", consisting of a Preamble and eight short principles (for example, "Software engineers shall act consistently with the public interest.") Each principle bears a key-word: Public, Client and Employer, Product, Judgment, Management,Profession,Colleagues, and Self.

The Short Version, suitable for posting, is followed by the "Full Version", which has its own preamble and the same eight principles as in the Short Version (with the same key-word titles). Below each principle are anywhere from eight to fifteen specific rules (for example, 1.1 [In particular, software engineers shall, as appropriate] accept full responsibility for their own work.")

A third difference between the two codes is that, though about the same length, the SE code is much more specific than the ACM's. In part, this is simply a consequence of substituting specific rules for the ACM code's discursive Guidelines. But, in part too, the difference has a more fundamental cause. The ACM code covers a great many activities related to computing; the SE code covers the work of one profession, software engineering. The SE code can be more specific because there is an underlying occupation with a relatively welldefined practice to be guided.

ACM Process
How did these two codes come about? Before the present ACM code, there was another, what I would describe as a "disciplinary code", that is, one designed to work in the way the criminal law does, to provide standards for administering discipline. In 1991, Ron Anderson, former president of the ACM Special Interest Group in Computers and Society, received a grant from ACM to revise that code. He wanted a broad base of contributors. In February 1991, at the annual ACM Computer Science Conference, he recruited several people to work on the new code. He circulated a first draft, primarily an outline, at the Conference on Computing and Values later that year. The first reaction to this first draft was not good, primarily because it was mistaken for the final draft. The Conference nonetheless provided a good opportunity to do concentrated work on the code.

The process of creating a code of ethics, especially winning adoption, is always political. External considerations including everything from whom this will help or hurt to who wrote what distract from the real work. As our little working group realized this, we revised the code accordingly. Let me give one example of this political work.

Imperative 4.1 now simply urges ACM members to "Be fair and take action not to discriminate", but it originally included a short list of prohibited subjects of discrimination. Various special interest groups wanted to add their own interest to the list. To avoid an ever-expanding list, we needed to make clear that our list was not intended to be exhaustive. So, we moved the entire list from the Imperative to the corresponding Guideline. The generality of the Imperative now captures all types of discrimination. The Guideline provides enough specificity.

The third draft was published in Communications of the ACM with a ballot asking members to vote on each item in the code. The vote was favorable, except for one provision covering copyright. We revised again. Three members of the committee that wrote the code - of which I was one - then presented the code at the morning session of the ACM Council on 16 October 1992. Since the presentation went well, we did not stay for the afternoon session at which the code was to be voted on. That was a mistake. The Council made a number of revisions before coming to a final vote. Some of those revisions were significant. I believe that we could have prevented those revisions had we been there to explain why we had done things the way we had. The lesson I took away from that experience is that those who know most about a proposed code must stay with it until it is safely passed. You can't expect those who have not worked on the drafts and participated in extended discussions about them to understand the final product as well as those who did.

SE Process
The process by which the ACM got a new code was relatively simple compared to the process by which the software engineers got theirs. The SE code was the work of two large societies rather than one, societies that, though sometimes cooperating, are always competing. They are also quite different societies. The ACM is primarily American, primarily concerne with computers, heavily academic. The IEEE is an international engineering society (with a very large American division). Its Computer Society section is just one interest group among many; the membership of that section, like IEEE membership generally, is primarily drawn from industry.

Having to maintain cooperation between two such societies made every step of the process of writing the SE code more difficult than the corresponding step in writing the ACM code. Even minor actions required the joint approval of, or a compromise between, the two societies.

Though the SE code took much longer to write than did the ACM code, the result was at least as good. The IEEE has elaborate procedures for writing and approving technical standards. The SE code was reviewed like an ordinary technical standard. The procedures required formal reviews in various countries at various stages. The reviews provided good input. The IEEE procedures also prevented the sort of last-minute amendments that occurred when the ACM code was adopted. By the time the SE code came up for a final vote in the two societies, everyone voting on it had already been involved in the process. It was unlikely that there would be any last minute surprises.

Lessons
I have been pleasantly surprised at how successful the SE code has already been. A number of companies have adopted it as their standard of practice. Part of the attraction of the SE code may simply be that it fills a void. There is no other document that provides the same sort of guidance for people who design, develop, test, and maintain software. But perhaps another reason is that the code is specific enough to offer real guidance. I have noticed two typical responses from people reading the code. One is, "Nothing new here." The other is, "That is just what we should be trying to do." It is this second response that has made the code a success. For example, there was a company having serious software problems. Its CEO distributed the SE code to different departments, asking what standards they were following and not following. They used the code to clean house.

That's one lesson I'd draw from my experience. Specificity helps. Another lesson is to take into consideration the audience that will be looking at the code, have a process that involves as many of them as early as possible, and have in place a well-planned procedure for adoption. And, of course, every project needs to include some people ("closure freaks") who get upset if the project is not moving along.