DISCOVERING EMBEDDED VALUES IN SOFTWARE

Abstract: This is a two part activity to familiarize students with a ubiquitous issue in design: the necessary inclusion of value choices in any technology. This exercise should be done early in the term since it provides a broad introduction to many of the design issues inherent in the course. The exercise consists of two parts:

1. a take home group exercise that should take 5 minutes to explain in class, 30-45 minutes to complete as homework, and between 5 and 30 minutes to resolve the next class day. The take home exercise asks groups of students to come up with a conceptual design for software, and arranges the assignment so that gender-based stereotypes are likely to be evident in their designs. Some students are assigned to design software for boys, others for girls, and others for students (gender unspecified).
2. an in-class exercise that takes about 15 minutes. The in-class exercise asks students to identify the assumptions made about the users of a product.

Goals for the activity: To introduce students to some of the effects of not considering the environment in which a product is used. To introduce students to the unintentional power they have over users of their products. To make students aware of the way their assumptions about users effect the software they design.

Knowledge / skills / attitudes to be developed (behavioral objectives): Introduction to the following ImpactCS principles or skills:

• Social Principles and Skills
• ES4.1 The social context influences the development and use of technology
• ES4.2 Power relations are central in all social interaction.
• ES4.3 Technology embodies the values of the developers.
• ES4.4 Populations are always diverse.
• ES5.1 Identifying and interpreting the social context of a particular implementation.
• ES5.2 Identifying assumptions and values embedded in a particular system.
• Ethical Principles and Skills
• ES2.2 Ethical choices cannot be avoided.
• ES3.2 Identifying stakeholders in concrete situations.
• ES3.3 Identifying ethical issues in concrete situations.

Procedure: Hand out the assignments sheet and explain that you want groups/individuals to complete this assignment before the next class day. You can have them form small groups outside of class or do the worksheet as individuals. In a large class, doing groups allows you to have all the designs presented in class the next day. Having individuals do the assignment mmaens you get more of a range of different designs.

Edit the assignment sheets to produce two or three versions. If you decide to do two versions, choose the "girls" and "students" versions, since this is the most informative comparison. Including the "boys" version replicates the original Huff & Cooper (1987) design, but is not required to get a discussion started in class.

Print out and collate the worksheets so that 1/2 (or 1/3 depending on your choice of conditions) of the groups or individuals get one asignment and 1/2 get the other. Do not let the class know that there are different versions. Emphasize that you want people to work alone (or only within their groups) because you do not want the designs to be influenced by each other for this exercise. Let students know that they should exercise their creative license, especially when it comes to choosing a "theme" for the software they design. The attached worksheet leads the students through the process of coming up with their conceptual design for the software.

When students return to class the next time, ask them to present their designs to the class (2-3 minutes for each should be suficient). Ask students if they noticed any similarities or differences in the program designs. Some programs (those for boys and students) are likely to take themes of violence, use competition as a motivator, require eye-to-hand coordination, etc. Other programs are likely to provide students with control over their experience (e.g. choice of "level") and be more straightforwardly "learning tools." These will most likely be the programs designed for "girls." The ensuing discussion might center on any of the topics mentioned above in the "objectives" section. Be sure to focus the discussion on the the way values are embedded in the design of software.

As an aid to making this more general point, after the discussion regarding the programs has come to some conclusion, choose a concrete, familiar, and simple technological artifact (the thermostat, a student's wristwatch, an umbrella). Ask students to write privately about the assumptions the design of the item makes about its users. After a few minutes have passed, ask them to pair up and compare their observations. Then have them share their observations with the class as a whole (think-pair-share). It is important to choose a real artifact in the room that everone can see. This exercise is almost impossible to do with a "hypothetical" thermostat, since it is the design choices in making the real artifact that carry the embedded values.

Assessing outcomes: This is not a graded exrecise, but students might be asked to write a reflection paper on the exercise or to do the exercise on their own later with a particular program (a harder task, but doable now that they have some practice).

Additional remarks: This is a robust effect and differences between the designs based on condition are highly likely to emerge. Even if differences in the design do not emerge, you can share the results of the Huff & Cooper (1987) paper, explain that this exercise has often produced the effects that paper shows, and congratulate your students for not falling into that particular trap.

If you are short on time, you should at least read the original Huff & Cooper article. In it you will find useful detail (e.g. women comprised most of the sample of designers for the study, but the bais effect was still shown). The Friedman & Nissenbaum (1996) article is likely the next best thing to read. Friedman also has an edited book on the subject that is listed in the references.

It is important to discuss the gendered nature of our expectations for "users," but don't let this become the only issue discussed. If you are insistent (and borrow from Friedman & Nissenbaum, 1996), you can make the more general points. The exercise is about the ways that values are embedded in the design of software, and gender expectations are simply one example of these values we hold.

huff@stolaf.edu

http://www.stolaf.edu/people/huff

Page maintained by: kwb@csee.usf.edu