Action Ethics for a Software Development Class
list of questions. That is explained beneath the questions.
1. What are the advantages of the new version of this
2. Are there any disadvantages of the new version?
3. Did you have any questions about the changes when they
were specified to you?
4. Do you foresee any problems with this new version when
the program is converted for use with real patients instead
of simulated patients?
5. Do you foresee any problems that might arise for patients
with this program? For nurses? For the hospital?
6. Do you foresee any safety concerns with turning off the
audible alarm after 30 seconds?
7. Do you think that 30 seconds was sufficient time for the
alarm bell to sound? Why or why not?
We expect that as the class works through these questions,
eventually a student will suggest that turning off the alarm
sound might cause problems when this program is converted
to real patients. If the alarm bell is turned off, or turned off too
quickly, the warning might be ignored or never noticed. The
patient may suffer if health professionals do not notice that
there is a warning about the patient’s vital signs. If a patient
suffers harm, nurses may be reprimanded for not responding in
a timely fashion. The hospital might be sued for negligence. It
is important that these issues be put on the table. Once at least
one student raises this issue (perhaps as one concern among
others), the instructor can move to a discussion of this specific
aspect of the revised program.
At this point, the instructor should encourage a discussion
about the advisability of turning off the audible alarm. Eventually, the instructor should ask for alternatives to the “ 30 second
rule” that was used in Version 2. Eventually one of the students
(or the instructor if necessary) will suggest a means to turn off
the audible alarm manually. This could be appropriate, it might
be argued, if a nurse discovers the problem indicated by one or
more vital signs going out of range, and has taken appropriate
action. (That is, after the audible alarm has served its purpose,
it can safely be turned off.)
The instructor now tells the students to make that change in
the program. The specification is as follows:
“Add functionality to Version 2 to make a Version 3 that al-
lows manual turning off of the audible alarm. Until the alarm is
turned off manually, it should keep sounding. The visual alarm
should stay on whenever a vital sign has gone out of range.”
A THIRD VERSION OF THE PATIENT
Our Version 3 is available at [ 13]. This program adds a button
that turns off the audible alarm. After students have produced
their third version of the program, they should look at their own
and others’ versions. After those examinations, the students are
broken up into small groups to discuss the following questions:
1. Does the manual system function as specified to turn off
the audible alarm?
2. Can you think of any problems with this system design?
3. If a user were deaf or colorblind, would the current version
be sufficient? Why or why not?
4. Should anyone be able to manually turn off the audible
alarm, or should only some users be authorized?
5. In at least one version of this program, numbers start out
black, and then turn red when a vital sign moves from
normal to abnormal. Should the numbers turn back to
black if the vital sign in question returns to the normal
range? Why or why not?
6. Can you think of any other weaknesses of this version
of the program with respect to its eventual use with real
The instructor should list any weaknesses that come up in
the discussion of these questions. At some point, the instructor should invite the students to suggest program modifications
that would address one or more of those weaknesses. For example, someone may point out that only authorized medical
staff should be allowed to turn off the audible alarm. This could
be accomplished with a password protection for the “turn off
the alarm” feature. If there were password protection, then we
could envision having other protected functionality, such as resetting the simulated vital signs to normal.
It seems likely that the discussions will sometimes focus on
the difference between a simulated patient monitoring system
and a system that monitors actual human patients. We think it
is important for the instructor to acknowledge the important
distinction between those two kinds of systems, but then also
point out that a simulated system might someday be converted
to a system for real patients. The instructor should point out
that in the specification given for the system under consideration in this exercise, the conversion to a system monitoring
human patients was explicitly mentioned in its first sentence.
This possibility means that decisions made for monitoring a
simulated patient could indeed have consequences for human
patients in the future.
After the discussion that ends Phase 3, the instructor may want
the students to change their Version 3 implementations into a
Version 4 that improves some of the weaknesses of Version 3.
Whether a Version 4 is produced, we think this exercise should
end with a final phase in which students reflect on the rest of
the exercise. Individually, in small groups, or as a class, students
should discuss the following questions. Depending on how
much time the instructor wants the students to spend on this exercise, their response to the questions could be verbal or written.
1. At any time during this exercise, did you have questions
about the software you were asked to write that you