1 page

profileMr.Q
ch04.pdf

Professional Ethics

 What is Professional Ethics?

 When applied to computing and information technology (IT), professional ethics is

a field of applied ethics concerned with moral issues that impact computer/IT professionals.

Why a Separate Category of Professional Ethics?

 Arguably, the same ethical rules involving honesty, fairness, and so forth that apply to ordinary individuals should apply to professionals as well as.

 So, if it is wrong for ordinary people to steal, cheat, lie, and so forth, then it is wrong for professionals to do so as well.

 Why, then, is a separate field of study called "professional ethics“ needed?

Separate Category of Professional Ethics (Continued)

 Some ethicists argue that some moral issues affecting certain professionals are sufficiently distinct and specialized to warrant a separate field of study.

 Others ethicists argue that professionals can have special moral obligations that exceed those of ordinary individuals.

 To understand these arguments, we need to examine what is meant by terms such as profession and professional.

What is a Profession?

 Harris, Pritchard, and Rabins (2004) note that the term “profession” has evolved from a concept that was once associated with people professing a religious or monastic life to one that now has a more secular meaning.

 “Profession” was used to describe a person who made a public promise to enter a “distinct way of life” with allegiance to “high moral ideals.”

 Later, the term came to refer to anyone who “professed to be duly qualified.”

 “Profession” has now come to mean an “occupation in which one professes to be skilled in and to follow.”

Who is a Professional?

 Professionals who comprise a given profession also tend to have certain defining attributes and requirements.  E.g., medical doctors, lawyers, accountants, etc.,

find themselves in situations in which their decisions and actions can have significant social effects; their roles and responsibilities can exceed those of ordinary individuals.

 Sometimes these roles and responsibilities can differentiate professionals from others (see, for example, Buchanan, 2004).

Who is a Computer/IT Professional?

 A computer/IT professional might be viewed as anyone who is employed in the computer, IT, or information/communications fields.

 A computer/IT professional might be also be viewed in more narrow terms, in which case only software engineers would be included.

 There are various gradients in between the two ends of this spectrum.

Definition of a Computer/IT Professional (Continued)

 A computer/IT professional could be defined in a way that includes software engineers and their teams,  E.g., software quality analysts, software technical

writers, network administrators, software managers and supervisors.

 A software engineering team includes those who participate directly in the analysis, specification, design, testing, development, and maintenance of software systems.

Do Computer/IT Professionals Have Special Responsibilities?

 Don Gotterbarn (2001) points out that software engineers and their teams are have significant opportunities to:

 (i) do good or cause harm;

 (ii) enable others to do good or cause harm;

 (iii) influence others to do good or cause harm.

Critical-Safety Software

 Gotterbarn suggests that the roles and responsibilities involved in the development of safety-critical systems is a differentiating factor.

 A "safety-critical system“ refers to computer systems that can have a direct life-threatening impact.

Safety-Critical Software (Continued)

 Examples of safety-critical software systems and applications typically include:

 aircraft and air traffic control systems

 mass transportation systems

 nuclear reactors missile systems

 medical treatment systems.

Additional Safety-Critical Systems

 Kevin Bowyer (2001) extends the range of safety-critical applications to include software used in the:

 design of bridges and buildings;

 election of water disposal sites;

 development of analytical models for medical treatment.

Professional Codes of Ethics

 Many professions have established professional societies, which in turn have adopted codes of conduct.  The medical profession established the

AMA (American Medical Association),

 The legal profession established the ABA (American Bar Association).

 Both associations have formal codes of ethics/conduct for their members.

Professional Codes for Computer/IT Societies

 The computing/IT profession also has professional societies, which include:  The Association for Computing (ACM);

 The Australian Computer Society (ACS);

 The British Computer Society;

 The Institute for Electrical and Electronics Engineers (IEEE);

 IEEE Computer Society (IEEE-CS).

Purpose of Professional Codes

 Professional codes of ethics are often designed to motivate members of an association to behave in certain ways.

 Four primary functions of codes are to:  inspire,

 guide,

 educate,

 discipline the members.

Criticisms of Ethical Codes

 John Ladd (1995) argues that ethical codes rest on a series of “confusions” that are both "intellectual and moral."

 His argument can be analyzed in terms of three main criticisms:  (1) ethics is basically an "open-ended, reflective, and critical

intellectual activity“ (that cannot be simply codified);

 (2) specific codes of ethics introduce confusions with respect to micro-ethics vs. macro-ethics (within a profession);

 (3) because codes can have a disciplinary function, they become more like legal requirements than ethical rules.

In Defense of Professional Codes

 Gotterbarn argues that we need to distinguish among three aspects of professional codes, because they can function as:

 codes of ethics;

 codes of conduct;

 codes of practice.

In Defense of Professional Codes (Continued)

 Codes of ethics are "aspirational," because they often serve as mission statements for the profession and thus can provide vision and objectives.

 Codes of conduct are oriented more toward the professional and the professional's attitude and behavior.

 Codes of practice relate to operational activities within a profession.

Table 4-1: Some Strengths and Weaknesses of Professional Codes

Codes inspire the members of a profession to behave ethically.

Directives included in many codes tend to be too general and too vague.

Codes guide the members of a profession in ethical choices.

Codes are not always helpful when two or more directives conflict.

Codes educate the members of a profession about their professional obligations.

A professional code’s directives are never complete or exhaustive.

Codes discipline members when they violate one or more of the code’s directives.

Codes are ineffective (have no “teeth”) in disciplinary matters.

Codes “sensitize” members of a profession to ethical issues and alert them to ethical aspects they otherwise might overlook.

Directives in codes are sometimes inconsistent with one another.

Codes inform the public about the nature and roles of the profession.

Codes do not help us distinguish between micro- ethics issues and macro-ethics issues.

Codes enhance the profession in the eyes of the public.

Codes can be self-serving for the profession.

Strengths Weaknesses

Conflicts of Professional Responsibility: Employee Loyalty and Whistle-blowing

 What, exactly, is employee loyalty?

 Do employees and employers have a special obligation of loyalty to each other?

 Should loyalty to one’s employer ever preclude an employee from "blowing the whistle" in critical situations?

 In which cases can whistle-blowing be justified?

Do Employees Have a Special Obligation to Employers?

 Some believe we have a prima facie obligation of loyalty in employment contexts.

 In other words, all things being equal, an employee should be loyal to his or her employer and vice versa.

Employee Loyalty and the Outsourcing of Programming Jobs

 Many computer programming jobs in the U.S. are now being “outsourced” by major corporations, such as IBM, to countries where programmers are willing to write the code for much lower wages.

 Not only does this practice raise questions for employee loyalty, but it could also affect the future of the computer profession in the U.S. if young people are discouraged from entering the programming field because of having their high-skilled jobs eliminated via outsourcing (Baker and Kripalani, 2005).

Employer Loyalty (Continued)

 Consider a case in which an employer continues to keep an employee on the payroll even though that employee has a chronic illness, which causes her to miss several months of work.

 Also consider cases in which several employees are kept on by a company despite the fact that their medical conditions have caused the corporation's health insurance costs to increase significantly, thereby reducing the company's overall earnings.

Employer Loyalty (continued)

 Consider a recent case involving the owner of Malden Mills, whose physical plant in Massachusetts was destroyed by fire.

 The mill's proprietor, Aaron Feuerstein, could have chosen to rebuild his facility in a different state or country where employees would work for lower wages.

 Instead, Feuerestein continued to pay and provide benefits for his employees while a new facility was being built in Mass.

Do Computer Professionals Have Special Obligations of Loyalty to Their Employers?

 They have to balance their obligation of loyalty owed to an employer against other obligations of loyalty they also may have?

 Loyalty is not something that an employee must give exclusively or blindly to one’s employer.

 Loyalty should also be seen as an obligation that individuals have to society as a whole, especially where safety and health issues are at stake.

Divided Loyalties

 Divided loyalties can result in serious conflicts for employees.

 In certain cases, the moral dilemmas they generate are so profound that an employee must determine whether to "blow the whistle."

Whistle-blowing

 What, exactly, is whistle-blowing?

 Sisela Bok (2003) defines a whistle blower as an individual who makes

“revelations meant to call attention to negligence, abuses, or dangers that threaten the public interest.”

Whistle-blowing (Continued)

 Bok notes that whistle blowers “sound an alarm” from within the organizations within they work.

 She also notes that whistle blowing can be viewed as a form of dissent, because those who blow the whistle make public their disagreement with their employers or with some authority.

 While dissent can include all forms of disagreement (e.g., religious, political, etc.), whistle blowing has the “narrower aim of casting light on negligence or abuse, or of alerting the public to a risk.”

Whistle-blowing (Continued)

 Bok defends whistle blowing in certain cases, where other alternatives have been “considered and rejected.”

 She also believes that it should remain as a “last alternative” due to its “destructive side effects.”

Whistle-blowing (Continued)

 In the context of engineering, whistle-blowing incidents often occur in attempts to alert the public to a potentially unsafe product. They can occur because of either:

 (a) overt wrongdoing (where an employee informs the public about the immoral or illegal behavior of an employee or supervisor);

 (b) negligence (e.g., where one or more individuals in an organization have failed to act).

When Should an Employee “Blow the Whistle”?

 Colleen Rowley, an FBI employee, came forth to describe the way in which critical messages had failed to be sent up the Federal Bureau's chain of command in the days immediately preceding the tragic events of September 11, 2001.

 Was it appropriate for this individual to blow the whistle on her supervisor?

 Was she also possibly being disloyal to her supervisor and fellow employees in doing so?

When Should an Employee “Blow the Whistle” (Continued)

 Should individuals in positions of authority in corporations such as Enron and WorldCom have blown the corporate whistle about the illegal accounting practices in those firms?

 One could argue that failing to blow the whistle in the Enron case resulted in thousands of individuals losing their retirement savings, and in some cases their entire life savings.

Cases Where Whistle-blowing Could Have Saved Human Lives

 Consider two (now) classic cases where whistle blowing could have saved lives:  Challenger Space Shuttle (problems with faulty O-

rings);

 Ford Pinto (problems with a faulty gas tank).

 Review the BART scenario (described in the textbook) involving problems with a faulty computer system affecting a mass transportation system.

Controversial Political Issues Involving Whistle-blowing

 Review the SDI (Strategic Defense Initiative) scenario (described in the textbook):

 David Parnas blew the whistle on SDI because of three factors (Bowyer, 2001):  1. The specifications for the software could not be known

with any confidence.

 2. The software could not undergo realistic testing.

 3. There would not be sufficient time during an attack to repair and reinstall failing software (no "real-time" debugging).

Criteria for Blowing the Whistle in an Engineering Context

 Richard De George (1999) offers some specific conditions for when an engineer is either:

 (a) permitted to blow the whistle;

 (b) obligated to do so.

When an Engineer is Permitted to Blow the Whistle

 In De George’s model, one is permitted to blow the whistle when the:  1) harm that will be done by the product to the

public is serious and considerable.  2) engineers (or employees) have made their

concerns known to their superiors.  3) engineers (or employees) have received no

satisfaction from their immediate supervisors and they have exhausted the channels available within the corporation, including going to the board of directors.

When an Engineer is Required to Blow the Whistle

 Two additional conditions are needed for an engineer to be required to blow the whistle:  4) The engineer has documented evidence that

would convince a reasonable, impartial observer that his/her view of the situation is correct and the company policy wrong.

 5) There is strong evidence that making the information public will in fact prevent the threatened serious harm.

Defending De George’s Criteria

 Ladd (1991) believes that requiring engineers to blow the whistle in non-extraordinary cases (such as in De George's conditions 1-3) can be undesirable from an ethical point of view because it demands that these individuals be "moral heroes."

 Ladd agrees with De George that engineers should not have to be heroes or "saints."

An Alternative Strategy

 De George and Ladd seem correct in claiming that engineers should not be required to be moral heroes or saints.

 But others may also be correct in noting that engineers, because of the positions of responsibility they hold, should be expected to make greater sacrifices.

A Compromise View

 Michael McFarland (1991) argues that, collectively, engineers might be held to a higher standard of social responsibility than ordinary individuals.

 However, he also argues that the onus of responsibility should not fall directly on engineers as individual engineers.

 Rather, it should be shouldered by engineers as members of the engineering profession.

McFarland’s View (Continued)

 McFarland's model is based on the assumption that, as moral agents, we have a prima facie obligation to come to the aid of others.

 In describing the nature of this obligation, he uses a non-engineering analogy involving the infamous Kitty Genovese case.

 Genovese was murdered outside her apartment building in NYC, when no one came to her aid.

McFarland’s Argument (Continued)

 McFarland draws from the important lessons learned from the Genovese case, arguing that when no other sources of help are available, engineers should take responsibility by banding together.

 If engineers act as individuals, they might not always have the ability to help.

 If they act collectively, however, they might be able to accomplish goals that would otherwise not be possible (as individual engineers).

McFarland’s Argument (Continued)

 McFarland believes that an engineer's work must be seen in a wider social context

 i.e., in its relation to society.

 Unless engineers work collaboratively on ethical matters, McFarland believes that they will not be able to meet all of their responsibilities.

McFarland’s Argument (Continued)

 McFarland's model encourages engineers to shift their thinking about responsibility issues

 from the level of individual responsibility (at the micro-ethical level)

 to responsibility at the broader level of the profession itself (i.e., the macro-ethical level).

Responsibility, Liability, and Accountability

 Traditional models of responsibility require that two conditions be satisfied:  causality,

 intent.

 For example, some agent, X, is held morally responsible for an act, Y, if X caused Y (or intended to cause Y).

Responsibility (Continued)

 A person could be held responsible for causing some outcome, even if he or she did not intend the outcome.

 E.g., Robert Morris, who launched the "Internet worm" in 1988, claimed that he did not intend for the Internet to be brought to a standstill.

 Morris was still nonetheless held responsible for the outcome caused by his act of unleashing the computer worm.

Responsibility (continued)

 Agents can also be held responsible when they intend for something to happen, even if they ultimately fail to cause (or bring about) the intended outcome.  E.g., suppose a disgruntled student intends to

blow up a computer lab, but is discovered at the last minute and prevented from doing so.

 Even though the student failed to carry out his objective, we hold the student morally culpable because of his intentions.

Liability vs. Responsibility

 Liability is a legal concept.

 It is sometimes used in the narrow sense of "strict liability."  To be strictly liable for harm is to be liable to

compensate for it even though the party that is liable one did not necessarily bring it about through faulty action (e.g., when a someone is injured on a person’s property).

 In liability incidents, the moral notion of "blame" may be left out.

Accountability (vs. Liability and Responsibility)

 Helen Nissenbaum (2007) argues that responsibility is only part of what is covered by the (broader) notion of accountability.

 For Nissenbaum, accountability means that someone, or some group of individuals, or even an entire organization is answerable.

Accountability (Continued)

 Nissenbaum points out that in cases of accountability,

...there will be someone, or several people to answer not only for malfunctions in life- critical systems that cause or risk grave injuries and cause infrastructure and large monetary losses, but even for the malfunctions that cause individual losses of time, convenience, and contentment.

The Problem of “Many Hands” in a computing Context

 Because computer systems are the products of engineering teams or of corporations, as opposed to the products of a single programmer working in isolation, “many hands" are involved in their development (Nissenbaum, 2007).

 It is difficult to determine who, exactly, is responsible whenever one of these computer or safety-critical system failures/accidents results in personal injury/harm to individuals.

The Problem of Assigning Responsibility when “Many Hands” are Involved

 Two problems for assigning responsibility using the classic model of responsibility (as apparent in the classic Therac-25 incident described in the textbook):  (i) we tend to think of responsibility as something

that applies to individuals but not to groups (or collectivities);

 (ii) we tend to think of responsibility in exclusionary terms: If X is responsible, then Y is not, and vice versa.

Accountability vs. Responsibility

 Accountability is a broader concept than responsibility because:

 (a) it is non-exclusionary, and

 (b) it can apply to groups, as well as to individuals.

Table 4-2: Responsibility, Liability, and Accountability

Moral Responsibility Legal Liability Accountability

Attributes of blame (or praise) to individuals.

________________________

Usually attributed to individuals rather than "collectivities" or groups.

___________________

Notions of guilt and shame apply, but no legal punishment or compensation need result.

Does not attribute blame or fault to those held liable. ___________________

Typically applies in the case of corporations and property owners.

___________________

Compensation can be required even when responsibility in a formal sense is not admitted.

Does not necessarily attribute blame (in a moral sense). ___________________

Can apply to individuals, groups of individuals, and corporations. _____________________________

Someone or some group is answerable (I.e., it goes beyond mere liability).

Assessing Risk

 Assessing Risks in Software Design

 Gotterbarn (2004) argues that we must take into consideration "ethical risks" associated with the entire "software development life cycle".

 The life cycle of software includes the maintenance phase, as well as the design and development stages.

Risk Assessment (Continued)

 Gotterbarn worries that the concept of risk has typically been understood in terms of three conditions, where software is either:  (i) behind schedule;

 (ii) over budget;

 (iii) fails to meet a system's specified requirements.

 Software can satisfy all three conditions and still fail to meet an acceptable standard of risk assessment (e.g., Aegis Radar System).

Risk Assessment (Continued)

 Gotterbarn believes that failures like the Aegis Radar System (described in a scenario in the textbook) are due to:

 (1) an overly narrow conception of risk;

 (2) a limited notion of "system stakeholders."

Risk Assessment (Continued)

 Gotterbarn argues that a model of risk assessment for software development that are based solely on cost effectiveness, i.e., in terms of criteria such as budget and schedule, is not adequate.

 Instead, the notion of risk analysis must be expanded to key additional factors, such as social, political, and ethical considerations.

Risk Assessment (Continued)

 Gotterbarn also notes that the stakeholders who are typically given consideration in risk assessment models for software development are limited to the:  (a) software developers,

 (b) customers.

Risk Assessment (Continued)

 Gotterbarn believes that a “limited notion of system stakeholders" leads to developing systems that have unanticipated negative effects (as it did in the case of the Aegis Radar System).

 So, Gotterbarn claims that we need a more robust model of risk assessment for software development.

Value Sensitive Design (VSD)

 If Gotterbarn is correct, we need to expand the notion of “stakeholder” to ensure that additional considerations affecting stakeholders are built into the process of designing software systems.

 Some also argue that we need to build into the design process a strategy that more broadly examines the potential impact of software development for “human values.”

 These assumptions have influenced a design process called Value Sensitive Design (or VSD).

VSD (Continued)

 Value Sensitive Design (VSD) is defined by Friedman, Kahn and Borning (2008) define VSD as

a theoretically grounded approach to the design of technology that accounts for human values in a principled and comprehensive manner throughout the design process.

VSD (Continued)

 Friedman et al. note that VSD has eight “key components”; it:

 seeks to be proactive: to influence the design of technology early in and throughout the design process.

 enlarges the arena in which values arise to include not only the work place…but also education, the home, commerce…and public life.

 contributes a unique methodology that employs conceptual, empirical, and technical investigations.

 enlarges the scope of human values beyond those of cooperation… and participation…to include all values, especially those with moral import.

 distinguishes between usability and human values with ethical import.

 identifies and takes seriously two classes of stakeholders: direct and indirect.

 is an interactional theory

 builds from the psychological proposition that certain values are universally held.

VSD (Continued)

 We can limit our examination to the third component, which distinguishes among three kinds of investigations that differentiate VSD from alternative models:

 conceptual,

 empirical,

 and technical.

VSD (Continued)

 In applying their three-part investigation model to the design of cookies technology, Friedman et al. note that the value of informed consent is involved.

 They also note that this value is important because it protects other human values such as privacy, autonomy, and trust.

VSD (Continued)

 At the level of conceptual investigations, the first level in the process, Friedman et al. consider the following questions:

 What values are implicated?

 How should we engage in trade-offs among competing values in the design, implementation, and use of information systems (e.g., autonomy vs. security, or anonymity vs. trust)?

 Should moral values (e.g., a right to privacy) have greater weight than, or even trump, non-moral values (e.g., aesthetic preferences)?

VSD (Continued)

 Friedman et al. note that empirical investigations are needed to evaluate the “success of a particular design” within the “human context” in which the “technical artifact” – in this case, cookies for Web browsers – is situated.

 Empirical investigations can be applied in situations where the activity affecting the technology can be “observed, measured, or documented.”

VSD (Continued)

 Empirical investigations are then followed by technical investigations, which:  (a) involve the proactive design of systems to

support values identified in the conceptual investigation;

 (b) focus on how existing technological properties and underlying mechanisms support or hinder human values

VSD (Continued)

 In a retrospective analysis of their technical investigation of the cookies technology embedded in the Netscape Navigator and Internet Explorer browsers, Friedman et al. describe their evaluations over a 5-year period.

 Their analysis includes the users’ perceptions regarding the use of cookies and how the implementation of that technology evolved in light of VSD.

VSD (Continued)

 Although we considered only one component of the overall VSD model, we can see how it could help to ensure that human values are taken into consideration at the outset, rather than in later stages of the software design process.

 We should also note that the example of designing cookies technology (that we illustrated) would not typically fall into the category of designing safety- critical or life-critical software, which can have a more significant impact for human values.