Chris Mueller

Practical Ethics for the Student Programmer

Christopher Mueller
January 28, 2005

Abstract

An ethical analysis is a vital stage in any software development lifecycle. Computer scientists can perform rigorous and methodical critical thinking exercises to thoroughly consider the ramifications of deploying their software. This process involves several steps, the first of which is understanding the socio-technical system (STS) in which the software will be used. Students at St. Olaf College have performed several ethical analyses that yielded interesting issues of real concern. Developers with a concern for ethics deliver high-quality software.

 

Introduction

An ethical analysis is a vital stage in any software development lifecycle. Computer scientists can perform rigorous and methodical critical thinking exercises to thoroughly consider ramifications of deploying their software. This process involves several steps, the first of which is understanding the socio-technical system (STS) in which the software will be used. This paper first looks at what computer ethics is and why it is important. It then provides an overview of techniques for performing an ethical analysis and considers two real-world ethical analyses prepared by student programmers.

 

What is Computer Ethics?

Computer ethics, in general, is the consideration of right and wrong actions within the realm of computing. Computer ethics considers such things as the safety of computer systems, copyright and intellectual property concerns, and how computers affect distribution of power within existing social hierarchies. Computer ethics is often the subject matter for science fiction stories: identity theft, villains with super-powerful computers, or artificial intelligence taking over the planet.

The name “computer ethics” applies to a range of topics. It includes efforts by philosophers to connect traditional ethical frameworks, such as utilitarianism or Kantianism, to modern computing. But it also includes public policy, codes of conduct, and corporate ethics. 1 This paper does not deny the spectrum of definitions that accompany the term “computer ethics”, but the focus here will be on practical ethical considerations: public policy, codes of conduct, computing standards, and so forth.

The Association for Computing Machinery (ACM) addresses ethics directly in its Code of Ethics and Professional Conduct. 2 The ACM Code is recommended behavior for any computing professional. People a distinct and powerful knowledge of computing, the ACM Code says, have a moral obligation to use their knowledge for moral causes and to actively pursue a right course of action in their work. Among other things, it discusses the following imperatives: avoid harm to others, be honest and trustworthy, honor property rights, respect privacy and confidentiality, and acquire and maintain professional competence. Adherence to the Code is voluntary only, but the ACM has reserved the right to terminate membership from its esteemed organization for those who have committed purposeful deviations from the Code.

The ACM Code of Ethics outlines some basic categories for ethical consideration. The ImpactCS study, conducted in 1994, delivers useful conceptual and practical tools for teaching computer ethics in a classroom. 3 The grid-based ethical analysis suggested by this study is described in detail later in this paper. For now, it is worth noting that the ImpactCS project identifies seven useful categories of ethical concern:

  1. Quality of Life
  2. Use of Power
  3. Safety
  4. Property Rights
  5. Privacy
  6. Equity and Access
  7. Honesty and Deception

Consideration of these seven ethical issues provides a solid basis for considering which actions are appropriate and which are not. For example, a software analyst could ask the question, “Will this database management tool provide sufficient privacy for our customers' personal information?” Answering this question Yes or No or Maybe provides a good starting place for thinking about real consequences of

 

Why Computer Ethics is Important

The most important reason to be an ethical programmer is because, by definition, it is the right way to program. But it is often difficult to pursue lofty philosophical virtues when served a difficult or budget-constrained project. There are, however, more practical reasons to pursue ethics in computer programming.

Reason number one: software makers should not be thrown in jail. There are laws and regulations governing the construction of software, and programmers serve their own best interest when they follow those laws and regulations. These laws include anti-trust regulations and copyright law, among others. There are often laws governing the actions of the end users of software as well, and software developers should be mindful of these. For example, software deployed at a university will likely interact with a student's personal information, such as transcripts, phone numbers, addresses, and enrollment status. FERPA (Family Educational Rights and Privacy Act) permits students over the age of 18 to control their records and allow or deny others to access them. 4 Consequently, software that processes this information in any way must consider FERPA and the boundaries it places on information dissemination.

Programmers should be ethical programmers because it makes the users of their software happy. Not only does this determine whether anyone will use a given program, but it can also determine how much income is generated selling such a program. Consider, for example, web applications. Web developers face the difficult task of providing consistent information to surfers using different graphical browsers, but they face the especially challenging task of allowing their sites to be accessible to users who use non-graphical browsers. Visually impaired surfers often use screen reading technology, which vocalizes the content of a web page. A good web site will deliver clean pages to both the screen reader and the graphical browser. But a poor web site will could deliver beautiful pages to one, and a mess of information to the other. The ethical programmer will recognize this need for equal access and build accessibility into the design of the software.

Another practical reason to consider computer ethics is safety. Software controls many safety-critical systems in hospitals, on busy highways, or in the military. If these systems were to fail, injury, disease, or death could result. (It is important to realize that software in these types of environments affects many people other than those who commissioned or purchased the software.)

Developers who show a concern for ethics will likely produce higher quality software than those that do not. A concern for ethics will address such issues as user satisfaction, security, and the software's robustness, all of which have a direct impact on the overall quality of the software. If any of these issues were not considered fully, the software could face cataclysmic failure.

 

How to Think about Computer Ethics

The primary goal of critical thinking about ethics is to determine how a piece of software will affect real people, and to connect design decisions with actual consequences for people and institutions.

The ImpactCS Framework 5

The ImpactCS framework for considering ethics attempts to cover a wide spectrum of ethical issues and levels of social analysis. It was developed in the late 1990s by a group of NSF-funded researchers at George Washington University as part of a curriculum for teaching social and ethical topics in computer science. The ImpactCS grid is a practical and useful tool for understanding how software can affect real people and institutions. An ethical analyst should consider each cell in the grid as a point of interest. Some of the cells will be of little or no importance, but this grid ensures that the full spectrum of ethical issues and social groups have been considered.

 

The ImpactCS Ethical and Social Analysis Grid

Social Levels

Topics of Ethical Analysis

Responsibility

Ethical Issues

Individual

Professional

Quality of Life

Use of Power

Safety

Property Rights

Privacy

Equity and Access

Honesty and Deception

Individuals

 

 

 

 

 

 

 

 

 

Communities & Groups

 

 

 

 

 

 

 

 

 

Organizations

 

 

 

 

 

 

 

 

 

Cultures

 

 

 

 

 

 

 

 

 

Institutional Sectors

 

 

 

 

 

 

 

 

 

Nations

 

 

 

 

 

 

 

 

 

Global

 

 

 

 

 

 

 

 

 

 

The Socio-Technical System

A socio-technical system (STS) is, as the name implies, a combination of people, hardware, and software. When performing an ethical analysis of software, it is important to understand in what context that software will be deployed. A socio-technical system is an elegant way to describe this context. An STS for a small liberal-arts college could include, though would not be limited to, IT staff, professors, students, administrative staff, existing mainframes and servers, public computing labs, administrative software, and web portals. Chuck Huff, et al, provide a framework for describing an STS. 6 They divide an STS into seven sections:

A software development team can gain valuable perspective about its software by listing as many relevant items as possible for each category. If the team is unfamiliar with the STS, it would be worthwhile to conduct an interview with someone who could provide a high-level overview of the people, procedures, etc. involved.

It is important to note that an STS could change with time, and that some of the most interesting ethical consequences could be a result of this change. For example, if a piece of software requires a highly qualified technician to perform routine maintenance, it is worth considering how the software will continue to function if that technician leaves the company. Or a student records management system, it is worth considering what will happen to a student's records once he or she graduates—how the records will be preserved or what access privileges will be given to the student or other members of the university.

 

Research Methodologies

Defining a socio-technical system or completing the ImpactCS grid is a good start to considering ethics of software, but these tools have their limits. Ethical analysts can learn much by performing in depth research on critical components of the STS.

Traditional, bookish research can provide great insight. Often the issues that arise in one piece of software have arisen in another, and some wise researcher will have written down problems encountered and their solutions. This can save a lot of time later. For example, suppose a developer is designing a user interface for someone who is colorblind. The developer could look up existing research on colorblindness and choose from that research a suitable color palette. Or the developer could perform her own research on colorblind test subjects and develop an appropriate palette based on her experiments. Obviously, using the existing research is much preferred.

There will be, however, many situations in which referring to existing research will be of no use. In these cases, other fact-finding tools are needed. One good way to discover information is to perform interviews. Interviews give the development team direct insight into the workings of an institution, and allow the team access to subtle or word-of-mouth information that might not be included in employee manuals or other forms of written documentation. Interviews also allow other people to contribute to the description of the STS, perhaps suggesting ideas that require much further inquiry. The quality of information taken from an interview depends on the quality of the questions and on the level of trust that exists between the interviewer and the interviewee.

Surveys are also useful research tools. They allow investigators access to large samples of people that would not be available if personal interviews were the only research tool being used. As with interviews, the quality of the question will determine the quality of the results, and questions should be worded carefully so that they do not possess an inherent bias. For example, a question like, “Do you have a lot of problems with network and internet access?” could be much better if reworded: “On a scale of 1 to 10 (with 10 being the highest), please rate your satisfaction with network and internet access from your office during the past year.”

Another useful research tool is a mock-up or testing of a prototype. If users can get a feel for the software before it reaches the final stages of development, they will undoubtedly provide valuable feedback that can be taken into consideration.

There are perhaps an unlimited number of worthwhile investigation techniques, and the ones mentioned here are only some of the possibilities. Observation of office spaces and study of procedure manuals are some other examples of further research techniques. When a development team has completed their research, they will likely discover issues that need to be resolved. Some of these might be issues that can be fixed by modifying the software itself, others might require training seminars, documentation, or a reworking of existing procedures and protocols.

 

Examples of Ethical Analysis

The St. Olaf Student Records and Registration System.

In the spring of 2004, the St. Olaf Registrar asked a class of computer science students to perform an ethical analysis of a new piece of software, the Student Records and Registration system. The goal of this software was to take the place of existing administrative tools and to provide a complete overhaul of information storage, retrieval, and processing. In addition to a new server and underlying structure, the system's goal was to provide administrators, students, and faculty with software or web interfaces to view and edit information pertinent to them and to build an online registration mechanism. The entire software suite was being developed in-house, and thus possessed flexibility that might not have existed otherwise.

To proceed with an in-depth ethical analysis, the class, which was led by Dr. Chuck Huff, divided into several teams who each focused on a particular portion of STS. For example, one team investigated the impact of the software for staff in the Registrar's office, and other teams investigated the software's impact on students and faculty. Each of these teams interviewed an initial contact—someone already familiar with the software—to gain a general understanding of the system. Each team prepared an in-depth STS report for its focus of study, then built tools for investigating the most critical components of the STS. Based on their investigations, teams composed recommendations and delivered them to the Registrar and the software development team at the end of the course.

The basic ethical issues in this software are fairly obvious. Any system that allows access to private student information must be secure, or it risks breaking the trust of students whose information is stored within and risks breaking federal laws such as FERPA (Family Educational Rights and Privacy Act). The system must be flexible enough to match the FERPA requirements that a student is allowed to hide her or his information from the public. Some other issues that fall into the “procedures” section of the STS include the new online registration procedures and interfaces as well as existing procedures and policies of the St. Olaf Registrar's Office: the goal of the new system was to provide an improved interface to student information, but if this interface were too greatly different from existing software and protocols, the Registrar's Office would need to rewrite their staff's job descriptions and perhaps hire or fire a substantial number of employees. This particular software system was, however, being closely supervised by the Registrar's Office and this concern was not as great as it would have been otherwise. The development team was largely aware of the issues just described, and it was the students' goal to discover some of the less obvious ethical issues.

What follows are two examples of student ethical analyses of the Student Records and Registration System. The first example is an analysis focuses on student interactions with the new system, and the second focuses on faculty.

 

The student team

The student teams' goal was to determine what interesting ethical issues would arise once students began interfacing with the new Student Records and Registration System. The most dramatic change for students using the new software would be during registration. The old method of registration was to shepherd students into a big room where they sat down with staff at dedicated computer terminals, and the staff typed in the students' requests for classes. Students were ordered first according to class rank, then according to a random distribution of last names. The new registration system, though not fully designed when this team began its work, would present students with a two-stage registration process: during the first stage, students would enter their preferences for classes, after which a “magic algorithm” sorted students into classes based on several criteria and allowed departments the option to drop or add classes based on student interest; during the second stage, students would refine and finalize their registration.

Other than the modified course registration process, students would experience little change. There would be an increase in web access to certain information, but this was deemed a minor issue considering the existing student proficiency in accessing information on the web.

Therefore, this team decided to concentrate its efforts on the new registration process. They conducted interviews with the Registrar, a faculty advisor to the development team, and, lastly and most importantly, they conducted a mock-up of the proposed online registration system. This allowed them to determine which parts of the system worked well or poorly, and to provide an informal forum for students to express their thoughts and concerns about online registration.

After completing these studies, the team made important conclusions concerning equity and access, property rights, and honesty and deception. Regarding equity and access, they determined that some students do not own computers and are occasionally confused by technical interfaces. For this reason, they wrote in their final report, “We believe the registrar's office should provide help and computers for the students to use during registration.” 7

The proposed registration system authenticated students using their campus network ids and a pin that they received from their advisors. This posed a security risk, since PINs could be passed among several people before reaching the students. The team recommended that the development team increase security by requiring student network passwords be a necessary addition to the authentication mechanism.

Regarding quality of life, the team discovered two important issues. The new system was The new system should support proxies for students who cannot register, even online. We propose that a proxy login with his username and password, and be able to register for either himself or his absentee using either his or his absentee's PIN.

The online system has the ability to check for prerequisites when a student is registering. The system must be flexible enough for students trying to get into classes for which they have not taken the prerequisites. We recommend that the new system allow a student to take classes without the proper prerequisites, but warn the student about the responsibility that he is taking on.

 

The faculty team

The faculty team's goal was to determine how the new Student Records and Registration System would affect faculty and administrative assistants in department offices. The new system was to give departments better management of courses and majors, and give faculty a single, powerful tool for advising their students. The team completed an STS report that focused on these people, and determined that its analysis should focus on five groups of people: advisors, faculty in general, department chairs, faculty with disabilities, and Academic and Administrative Assistants (AAAs). To perform their investigation, the team delivered a survey to the entire faculty, interviewed faculty with visual impairments, and conducted interviews with AAAs. 8

After completing their investigations, the team reached several important conclusions regarding the following ethical issues: quality of life, equity and access, and use of power. Regarding quality of life, they expressed concern that a new, automated registration system would decrease interaction between advisors and advisees, something that many consider essential to the health and livelihood of the campus. They recommended implementing a registration system that promotes interaction between advisors and advisees, perhaps forcing advisors and advisees to meet before registration.

The team concluded that accessibility was an important issue, since the software must be equally available to all members of the St. Olaf community. Specifically, web pages that followed the recommendations from the Web Accessibility Initiative and the Section 508 federal guidelines would ensure that those who have visual impairments were able to access the system. These guidelines discuss, among other things, the use of screen-reading technology. In addition, they found that colors on the user interfaces should be chosen with care so as to avoid delivering unreadable pages to people who are colorblind.

Furthermore, the team discovered concerns that the new system would reduce interaction between faculty and AAAs or otherwise reduce the role of AAAs within departments. This is a “use of power” issue, since faculty would be given more control over procedures that usually were filtered through the AAAs. The team recommended training AAAs to be experts in the system to allay this concern. This training would also build relationships between the departments and the development team and reduce the workload on the Registrar's Office when the switch to the new system was officially made.

This team's recommendations ensured that the new software provided equitable access to disabled faculty, that it preserved or promoted quality-of-life standards in place at the college, and that it did not significantly disrupt existing roles of faculty and staff within academic departments.

 

Co-Process Extension Tool

In the summer of 2004, work began on the CPET software. CPET, the Co-Process Extension Tool, is software that extends the functionality of existing course management tools (CMS), such as Moodle or WebCT. CPET is built as a client and server. The client was implemented as an Internet browser plug-in that interacts with web pages to provide access to co-processes—external services that are attached to the CPET server. For example, the CPET prototype allowed answers to certain quiz questions in a CMS to be processed by a Scheme language interpreter. In January of 2005, six computer science students continued work on CPET. After implementing several new features, they considered the ethical issues associated with the CPET software. These analyses were not as formal nor as rigorous as those in the previous example, but they nevertheless demonstrate the power of an ethical analysis.

Since CPET is a client/server application that uses network communications, it is inevitably vulnerable to network attacks. Also, CPET's core functionality lies in its arbitrary execution of Scheme or C++ code, which could give users of CPET more power than they should have. Several security measures have been taken to prevent unauthorized users from performing script or SQL injections, but the CPET team should certainly investigate this further and consider building a protected “sandbox” for executing Scheme or C++ code. 9

In an effort to make CPET more secure, the developers initially limited access to the CPET server to known client machines. This security technique can work for a limited number of CPET users in an isolated environment, but is not suitable for a wide-scale deployment of the software. The team recommended increasing the security of the CPET server in general to allow for world-wide public access.

The developers of CPET are exposed to several technologies and techniques that allow for the easy creation of spy-ware such as a password-sniffer. The developers of software must be trusted to not use their knowledge for malicious purposes, but it would be worth outlining the issues of spy-ware to future developers to make them aware of the power they possess.

Any of these issues—security, access, or abuse of power—could cause CPET to fail completely for its intended user base. For example, if the software is insecure, the server could become unusable; or if users are not able to access CPET from outside a local subnet they might not find the software usable at all.

In addition to these concerns, several of the CPET developers considered usability issues with CPET and researched Just-in-Time Teaching (JiTT) methods to determine how CPET might aid professors using JiTT. 10 They concluded that CPET's user interface is quite obvious and should not need major revisions in the near future. They also determined that JiTT methods can improve student comprehension of material significantly, raising test scores and grades.

 

Conclusion

Ethics are an important consideration for any development lifecycle. Developers that concern themselves with ethics are more likely to produce robust, reliable, safe, usable, and high-quality software. Tools such as the ImpactCS grid and the STS report, when augmented with interviews, surveys, or other research techniques, can aid investigators in discovering points of ethical concern in a given piece of software. Students at St. Olaf College performed ethical analyses of two major software projects. In one case the students were not developing the software themselves and were able to offer insightful and fresh recommendations, especially concerning equal access, to the development team. In the other case, the students were both the development team and the ethical investigators, yet they were still able to reach interesting conclusions, especially concerning equal access and security, about the software under consideration.

 

Acknowledgements

Special thanks to Dr. Chuck Huff, professor of psychology at St. Olaf College , for his invaluable insight into the ethics of computing and for his willingness to share and teach these insights to students. Thanks also to Dr. Richard Brown, professor of computer science at St. Olaf College , for building ethics curriculum into the computer science major at St. Olaf.

 

1 Computer Ethics: Basic Concepts and Historical Overview. Terrell Bynum. 2001. http://plato.stanford.edu/entries/ethics-computer/

2 ACM: Code of Ethics and Professional Conduct. 5/12/03 . http://www.acm.org/constitution/code.html

3 ImpactCS: Social and Ethical Impact of Computing. Sherri Braxton and Daryl B. Stone. http://www.seas.gwu.edu/%7Eimpactcs//index.html

4 Family Educational Rights and Privacy Act. http://www.ed.gov/policy/gen/guid/fpco/ferpa/index.html

5 Synopsis of the ImpactCS Project. Sherri Braxton and Daryl B. Stone. http://www.seas.gwu.edu/%7Eimpactcs//synopsis/index.html

6 ComputingCases.org: Socio-Technical System Main Page. Chuck Huff, et al. http://www.computingcases.org/general_tools/sia/socio_tech_system.html

7 Noah Dove, Aaron Etshokin, Matthew Handley, Pokie Speare. “Online Registration Final Report.” Paper presented at St. Olaf College for the CS 263: Ethical Issues in Software Design class. Northfield , MN . May 17, 2004 .

8 Andrew Johnson, Chris Mueller, Kim Newman, JinXia Ni. “Faculty Interface: Final Report.” Paper presented at St. Olaf College for the CS 263: Ethical Issues in Software Design class. Northfield , MN . May 17, 2004 .

9 Aaron Etshokin, Chris Mueller, Michael Smith. “Ethical Analysis of CPET: a Developer's Perspective.” Delivered to Professor Richard Brown for the CS 390: Capstone class. Northfield , MN . January 27, 2005 .

10 Robert Crawford, Rylan Gibbens, Joel Johnson. “Ethical Report for CPET.” Delivered to Professor Richard Brown for the CS 390: Capstone class. Northfield , MN . January 27, 2005 .

 

© cm