Background
Technology and computing systems play an increasingly significant role in our daily lives. As our world becomes more reliant on technology, it is vital to ensure that not only the creators but also the users of technology understand the ethical implications of their decisions. From issues related to privacy and security to concerns about algorithmic bias, accessibility, and the unequal distribution of technical burdens, there are numerous social and ethical considerations that shape how computing affects real people.
Teaching about these issues helps students develop a deeper understanding of the broader impacts of computing and empowers them to make informed decisions about the technologies they create and use. It also helps foster a more responsible and inclusive computing culture — one that prioritizes the well-being of individuals and communities.
Each week we will spend some time considering social and ethical issues connected to the material you just studied. The scenarios below are not hypothetical edge cases — they are grounded in real patterns that emerge when technical decisions meet human consequences.
How to Use These Scenarios
Read each scenario carefully. For each one, consider writing down your thoughts on the following questions before your small group discussion. You don't need to address every question — use them to help you think:
- Who are the stakeholders? Don't stop at the obvious. Think beyond who might be "at fault" to include those who were in a position to catch a problem and didn't, as well as those who were harmed by decisions they had no part in making.
- Where were the decision points? At what moments in the scenario could a different choice have been made? Who had the power to make it?
- Were poor decisions made in good faith? Were they the result of carelessness, cost-cutting, or reasonable judgment that turned out to be wrong? Does that distinction matter?
- What could have been done differently? What might have been the reasoning — technical, financial, or organizational — for not making a better choice?
- What connects this scenario to Week 1? What specific concepts from this week's material are at the heart of the problem?
After working through these questions, begin to form some opinions about what went wrong and, where it feels appropriate, who bears responsibility.
Scenarios
Scenario 1 — The Security Camera
A middle school installs a security camera system to monitor hallways and common areas. The cameras are purchased at the low end of the school's budget, and the footage is stored in a heavily compressed format to reduce storage costs. One evening, vandalism occurs in a hallway. When administrators review the footage, the image is grainy and pixelated — the result of low resolution and aggressive compression. A student is identified as the likely perpetrator based on the footage and is suspended pending further investigation. The student's family disputes the identification, arguing that the image quality is too poor to make a reliable determination. The student misses several days of school, including an important exam.
- How does image resolution and compression relate to the reliability of this evidence?
- Who made the decisions that led to low-quality footage, and at what point could those decisions have been revisited?
- What obligation does the school have when acting on ambiguous visual evidence?
- How might this scenario play out differently for students of different backgrounds?
Scenario 2 — The Name That Wouldn't Save
A regional hospital system upgrades its patient records software. The new system was built by a vendor using ASCII as its character encoding standard. During the rollout, staff begin to notice problems: patients with names containing accented characters — such as é, ñ, or å — or names from non-Latin scripts have their names stored incorrectly or truncated. In some cases, records cannot be found under a patient's actual name at all. A patient with the last name Nguyễn is checked in under a corrupted version of her name. When a family member calls to ask about her condition, the staff cannot locate her record. In another case, a medication allergy stored under a malformed name is not retrieved during an emergency lookup.
- What technical decision at the foundation of this system created these consequences?
- Who should have caught this problem, and when?
- Whose names work correctly in this system, and whose do not? What does that tell us about whose needs were centered during design?
- The vendor likely tested the software before delivery. What might those tests have looked like, and what might they have missed?
Scenario 3 — The Exchange That Couldn't Say "Aloha"
This scenario is based on a real event. You can search for "Hawaii health insurance exchange launch 2013 Hawaiian names" to find coverage of what happened, or read this summary.
In October 2013, Hawaii launched its state health insurance exchange — one of the online marketplaces created under the Affordable Care Act where residents could shop for health coverage. The launch was troubled in ways that affected many states that fall, but Hawaii's exchange had a distinctive additional problem: it could not correctly handle Hawaiian names.
Hawaiian names frequently include the 'okina — a glottal stop represented by the character ʻ — and the kahako, a macron placed over vowels to indicate lengthened pronunciation (as in Hāloa or Kāne'ohe). These characters are meaningful in Hawaiian orthography and appear in the legal names of many Hawaiian residents. The exchange's enrollment system, built on a character encoding standard that did not accommodate these characters, either rejected names outright, stripped the special characters silently, or displayed garbled text. Residents attempting to enroll under their legal names encountered errors or found their names corrupted in their records.
The exchange was eventually shut down in 2015 after spending over $130 million in federal funds, making it one of the most prominent ACA exchange failures. The encoding problem was one of several technical issues, but it was a visible and symbolic one: a system built to serve Hawaii that could not correctly represent the names of Hawaiian people.
- The 'okina and kahako are not obscure or rare — they are standard characters in the official orthography of the Hawaiian language and appear in many legal names. What does it tell us that a system built specifically to serve Hawaii did not account for them?
- Who should have been involved in the design and testing of this system, and who apparently was not?
- The encoding problem was one of several failures in the exchange. Does it receive more or less attention than a purely financial failure would? Why might that be?
- How does this scenario connect to the broader lesson from this week about the choices embedded in character encoding standards like ASCII?
Scenario 4 — The Video Assignment
A school district, energized by new instructional technology initiatives, adopts a policy requiring students in grades 6–12 to submit a short video reflection at the end of each major unit. Teachers are enthusiastic. The videos, they find, are more expressive and personal than written work. The district's technology coordinator recommends that students submit videos at "high quality" — at least 1080p — so that teachers can see facial expressions and read any written work students hold up to the camera. What the coordinator does not account for is that a significant portion of students in the district have limited home internet bandwidth, shared devices, or phones with limited storage. These students struggle to record, store, and upload large video files. Some submit late. Some submit lower-quality videos and receive feedback that their work is "hard to evaluate." A few stop submitting altogether.
- What does the file size of a one-minute 1080p video have to do with equity?
- What assumptions did the technology coordinator make, and where did those assumptions come from?
- Who benefits from the high-quality video policy, and who is burdened by it?
- What would a more equitable policy look like? What tradeoffs would it involve?
These scenarios are intended as starting points for discussion, not definitive case studies. You don't need to cover all four in depth — two discussed well is better than four skimmed. Bring your reactions — including disagreements — to your small group session.