Software engineering code of ethics

Reviewer: John M. Artz

I have serious reservations about whether software engineering qualifies, or should be made to qualify, as a profession. There are too many nagging questions. Having said that, however, I must also acknowledge that there are many problems within software engineering and related fields that need to be addressed. Professionalization is one possible solution, and probably the best one on the horizon. A joint committee of the IEEE and ACM is addressing the issue, and one of its initiatives is to define ethical standards. It is within that framework that the software engineering code of ethics introduced in this paper is offered. This code is based on three levels of commitment and eight guiding principles. The levels of commitment are ethical responsibilities derived from one's role as a human being, ethical responsibilities derived from being a professional, and ethical responsibilities associated with specific practices. The eight guiding principles are product, public, judgment, client and employer, management, profession, colleagues, and self. The three levels of individual commitment are fairly straightforward. Some of the guiding principles are more problematic. For example, Item 1.04 suggests that software engineers “ensure proper and achievable goals and objectives for any projects on which they work or proposed work.” I have been beating the goals and objectives drum for years in the classroom and on projects. I have yet to see this advice followed anywhere. Items 2.02 and 2.03 both say, effectively, “do not sign anything you do not understand.” While this is a laudable goal, software engineering would come to a standstill overnight if managers and employees had to understand every document they signed off on. The problem here is not that these practices are not highly desirable—they are. It is that they are unrealistic in today's software engineering environment. There has always been an unfortunate gap between academics and practitioners in software engineering, and assertions of this type widen that gap. It also seems as though this code of ethics might put software engineers in awkward situations. Since the profession is not strong enough to back individuals who take stands consistent with the code, they might just find themselves ethical and unemployed. Criticisms aside, I have to say that, on the whole, the committee has done an extraordinarily fine job at an extraordinarily difficult task. The paper contains a feedback form for readers to inform the committee of their views on the various items , which implies that this paper is not the final word. I would strongly encourage all interested parties to offer their support or concerns.