Please enable JavaScript.
Coggle requires JavaScript to display documents.
The Ethical Dilemma Faced by the Therac-25 Software Developer (Changes…
The Ethical Dilemma Faced by the Therac-25 Software Developer
Write the safety-critical software by yourself
Who could be hurt?
Hospitals using the product.
AECL
AECL quality assurance manager
Patients being treated with the unstandardized software.
Pros
Having written the software by yourself could serve as a booster for the person writing it
You could throw in new ideas and make a more efficient program
The cost of writing the program will decrease greatly because one person would do it
The software will be looked over thoroughly and known by the createor
Who could benefit?
The programmer who was paid all of the money to write the software himself
People purchasing the Therac-25 because one programmer means the cost of the product has the potential to be cheaper
The company who only has to pay one programmer
Cons
Not many people will be available to proofread or troubleshoot if only one person is working on the software
One person is in charge of everything rather than breaking up the work
It may take a while for it to get done because the lack of people working on it
If the one person quits it would be very difficult for a brand new person to pick up his work and begin to finish it
Whose rights may be abridged?
Patient's rights who are being treated with unstandardized software.
If everyone took Alternative 1?
Software would lose its quality due to the omission of following the ommonly held standards programmers typically use today..
Do not write the safety-critical software by yourself
Who could be hurt?
The company may not find anyone to help write the software and then lose the opportunity to develop the machine.
The initial programmer may have to share his wages with the new programmers.
The company will lose money due to hiring more programmers.
If the programming team misses something there are more people held responsible.
Pros
Having multiple people there is a better chance bugs will be found.
Programmers will hold each other responsible.
With multiple people you can assign tasks. One person is in charge of testing the software during alpha and beta phase. Another person in charge of safety checks with the programming. Etc.
Software will be finished quicker and more absolute.
Who could benefit?
The programmers. If they make software that is reliable than their reputation will improve.
The individual consumer of the software. If the software is more reliable because of the checks made by the programming team, the software will be safer for the user.
The company consumer of the software. With more people the chances of the software being complete and reliable increases.
Cons
Less glory or fame than if one person created the software.
If programmers do not check each others work there is more people with the potential to make a mistake.
Multiple programmers mean the cost will increase.
If someone drops from the project it could be hard for someone to pick up where they left off.
Whose rights may be abridged?
The lead of the software. With more people working on it, he/she has to share the credit for the program.
If everyone took Alternative 2?
Software would cost more money because of the amount of people working on each program.
All software would be more reliable as long as the team of programmers did their due diligence.
Relevant Facts
The programmer worked in an assembly language, which was often used during that time rather than other, safer languages because they desired rapid execution and low memory usage.
The Therac-25 relied much more heavily on the machine's software for control and hence for safety, which is not a safe practice.
The program was developed by one single person, working alone, which is not a safe practice.
The author of our classbook suggests the programmer's mistakes were due to hubris more than negligence.
Professor Douglas Birsch, applied ethicist, argues the programmer meets the 3 criteria for moral responsibility of this dilemma. 1) The programmer made or allowed the errors that directly caused radiation overdoses. 2) The programmer should have known that such a complex program could have bugs that were unlikely to be detected by testing. 3) The programmer knew the machine was potentially lethal.
The famous computer scientist, C. A. R. Hoare, who argued, “There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies." The author of our textbook describes the Therac-25 software as the epitome of the second way.
A medical physicist from Kennestone during the very first serious radiation burn called AECL to inquire if it were possible for the Therac-25 to cause a radiation overdoses, but AECL assured him such an occurrence was impossible. This is potentially the software developer's fault if he did not tell people that it is possible. Or maybe the guy on the phone knew it was possible but lied to the physicist.
Stakeholders
Atomic Energy of Canada Limited (AECL)
Hospitals using the Therac-25
Patients being treated with the Therac-25
Therac-25 operators
The programmer
AECL quality assurance manager
FDA
Decision
The decision is to NOT write the safety-critical software by yourself. The are far fewer people that could be significantly hurt by this decision and it reduces the risk of life-threatening issues. The major downside to this is cost of putting more people on the job, but as a whole, the program will very likely contain less errors and it will be more reliable. This decision will cause the most good for the highest number of people as it will reduce the probability of death or serious injury occurring in the patients who are being treated with the machine.
Changes that could prevent this dilemma
Perform software quality audits
After the incident in 1990, health care facilities became required by law to report incidents to both the manufacturer and the FDA
Safety-critical designs should be written clear and simply
People should be more skeptical of software
Software should not solely be responsible for safety
Software, especially safety-critical software, should be audited by more than one person with development documents as required by the FDA software-approval standards.
Use a different devise such as the Linear Accelerator Use for External-beam (LINAC)
Include all possible error codes in manuals