General
Teaching Tools
Case Materials
About the Social Impact Statement
About Social Impact Statements
The idea for a social impact statement originated with Ben Shneiderman's 1990 address to the Computers and Society special interest group of the Association for Computing Machinery. He proposed a model based on the environmental impact statement that would enable software designers to find out the social impact of the systems they design in time to incorporate changes in those systems as they are built.
Since then the SIS has caught on as a fine teaching tool at several institutions across the country. Faculty at the Unversity of Maryland, George Washington University, and the University of Texas at Austin have all used variations on this approach to help students understand the impact of the software systems they design.
Why include SIS in the Curriculum?
The idea for including an SIS in a class on social and ethical issues in computing came from a desire to have students see ethical and social issues as real problems that they might have to face in their careers. By identifying these problems in real systems--with some guidance from the instructor--they will have a chance to locate them within the complexity of the technical issues of the system.
This exercise provides students with the skills of locating these issues and thinking carefully about them, and the luxury of having the time to do so. The social impact statement is designed as a class project, to be done by teams of students, looking at real computing systems on or near campus.
These skills could be taken out of the classroom and profitably applied to systems design, and in fact this class project is designed precisely because many authors believe these skills will be useful in system design. But this description limits itself to the use of the SIS as a teaching tool.
The Scope Of The Project
As the major project paper for the Technology and Society class, students at St. Olaf College were asked to do a social impact statement on a real system on campus. With a little telephone work, the students found 12 systems on campus with faculty or staff who were willing to help them understand the systems they had in their charge.
The students called the faculty or staff in charge of these systems the students' "clients" and students were encouraged to deal with them in the professional manner that such a relationship suggested.
Some examples of the systems include: Computer Assisted Instruction or CAI programs in the medical school, the card access system to the dorms, cafeteria, and library, the database maintained by the health office, the modem pool, the campus public information system, and an emergency room patient intake system.
The list of relevant issues for any client's system was generated from the topic space suggested by the ImpactCS report on teaching social and ethical issues in computing [19]. This list provides a good starting place for matching social and ethical issues with the concrete aspects of the system under study. The list is obviously not comprehensive, but does serve a useful function in beginning an inquiry.
In addition to using this list to identify issues, students were also acquainted with Collins and Miller's Paramedic method [9] that begins with a comprehensive listing of the stakeholders involved in any ethical decision. Armed with a list of stakeholders for a system and a list of possible social and ethical issues, students can usually generate a quite plausible and comprehensive set of concerns with which to begin their inquiry.
Some of the systems were quite complex, and suggested more social and ethical issues than could be dealt with in a single class project. The campus public information system, for instance, brought up issues of privacy, reliability, property rights, the use of power, honesty, and a host of other issues associated with networks.
Students needed to quickly focus on one or two of these issues in order to make any headway in such a large topic space. One of the criteria used to help narrow the scope of an issue was a quick look at which issues had been given the most attention by the clients. Students were then encouraged to concentrate on those issues their clients had not considered.
Other methods also exist for paring the list of issues to consider. For instance one can investigate only those issues that seem the most dangerous, or those in which the client is most interested, or those that it would be the easiest to investigate. Of course the criteria one might use in a class project (e.g. can it be finished by novices in a few months?) will differ at times from those one would use in industry.
Goals Of The SIS
There are several goals of an SIS, and they flow from the practical nature of the undertaking. An SIS is not an attempt at publishable social science research, or a theoretical deconstruction of the meanings inherent in a computer system (though it may borrow from both of these approaches). It is a tool to allow students (and hopefully systems designers) to locate and deal practically with the social and ethical implications of the technology with which they are working.
A primary goal is to provide surprises about how the system works and the consequences of its operation, information that is not included in the standard story of how the system works. Safety engineers call these latent errors [31], because they lie unnoticed in a system until an accident or critical incident arises.
The idea of latent errors need not apply to only safety issues. It can apply as well to issues of equal access, privacy, property rights, quality of life, or any area where hidden or unnoticed aspects of the system can pose ethical challenges. Thus, the methods used to produce an SIS must be apt for uncovering these surprises--simply reading the specification sheets will not do.
In addition, the practitioner doing an SIS must be aware of the political issues involved in pointing out surprises to designers, managers, and operators of a system. Even if it is your job to do so, one must be politic in pointing out oversights to people you will need to trust to implement fixes.
A secondary, but still important, goal is to give the clients some practice in thinking about the ethical and social aspects of their own system. In a way, the process of thinking about the issues is as important as the product [37]. Even an extended inquiry into a system cannot be sure of turning up all the issues (or even the most important ones).
Sensitizing the designers, managers, and operators of a system to the social and ethical issues, and giving concrete examples of potential difficulties in the system, may make them more aware of the issues and more likely to detect other issues when they arise.
One way of doing this sensitizing is to provide clients with a document that will be useful in future modifications of the system, and that will point them to the literature describing the particular problems they face.