The Toothless ACM Code of Ethics

The railroad handbooks are written in blood. Every rule exists because someone died. Railroad accidents would seem completely unrelated to modern software development, but our software is quickly reaching the same point. People can die due to problematic software.

Contributing to this problem is the fact that we have no code of ethics with teeth. We'll see how this came to pass, through the Harvard Business School, and how it disproportionately affects women and persons of color. This power imbalance won't right itself; it likely requires an outside force such as antitrust remediation.

Day of Death

Death was in the air of a clear spring day near Tacoma, Washington (Figure 1, "O and W Wreck"). Passenger train no. 362 was running its scheduled route from San Francisco north to Seattle on May 12, 1913. This typical train carried three passenger cars (day coaches), a dining car, a Pullman sleeping car, three refrigerator cars, baggage car, and caboose.

Passenger locomotive No. 201 was absolutely typical of the Steam era. The whole engine was basically a high-speed water tank with fire box and the off chance of blowing up. The accident report notes "Engine No. 201 was of the Pacific type, weighing 149,020 pounds on its driving wheels, the engine and tender having a combined weight, ready for service, of 394,420 pounds."

This was a clear spring day near Tacoma. You will recall (if you were a railroad person in 1913) that there had been a Southern Pacific disaster a year earlier which threw pieces of locomotive weighing hundreds of pounds up to seven blocks away. "At least" 26 people had been killed, but we'll never know for sure since remains were beyond recognition.

Our fated train No. 362, under the control of Conductor Kramer and Engineman Dunlap, was running 38 minutes late. Our train was running the maximum allowed track speed, 60 miles per hour, eight miles short of Tacoma.

The track had been straight for several miles, took a slight curve and descended slightly, and straightened out again. It was a clear day, easy conditions, and No. 362 was literally "eating up the track."

When Safety is Optional

Engineman Dunlap noted men ahead working on that section of track. There was no slow flag or signal of any kind to indicate that the track was unsafe for high speed. Dunlap continued at full speed. The section workers were engaged in their annual replacement of railroad ties.

Rule No. 929 of the Northern Pacific Railway (who owned this section of track), referring to the duties of section foremen, explains:

When the track is to be made unsafe for trains at usual speed, a flagman will be stationed at a distance of not less than three-quarters of a mile (130 rail lengths) on each side of the obstruction and where there is an unobstructed view for at least a quarter of a mile beyond. Two torpedoes will be placed on the rail 60 feet apart on the engineman's side 10 rail lengths beyond the flagman. On the approach of the train the flagman will display caution signals until acknowledged by the engineman.

At a distance of not less than 35 rail lengths on each side of the point of the obstruction a red flag by day or a red light by night will be placed on the engineman's side where it can be plainly seen by an approaching train, and in addition, two torpedoes will be placed on the rails opposite each other so as to make one explosion. These stop signals must not be removed until track has been made safe for trains to proceed without stopping.

The railroad torpedo (Figure 2, "Railroad Torpedo") is a small explosive charge intended to make a lot of noise when the train engine crushes it with the front locomotive wheel.

Section Foreman Antrim decided that the work being done did not require warning flags or signals. He had 29 years' foreman experience backing that decision.

Four other passenger trains had passed over the section in the past two hours without incident, albeit traveling more slowly. Far from verifying the track's safety, those four trains' passage helped cause the accident.

Oregon-Washington Railroad & Navigation Company (the "O and W") train No. 362 began to bounce. When the locomotive engine reached a point where the section men were working the engine began to roll to one side. The engine was unbelievably heavy, weighing 74 tons on its driving wheels. The engine and tender had a combined weight of 197 tons.

To put this weight in perspective, consider the I-35W bridge collapse in Minneapolis, Minnesota, on August 1, 2007 (Figure 3, "Cars rest on the collapsed portion of I-35W Mississippi River bridge").

On November 13, 2008, the NTSB released the findings of its investigation. The primary cause of the collapse was the undersized gusset plates, at 0.5 inches (13 mm) thick. Contributing to that design or construction error was the fact that 2 inches (51 mm) of concrete had been added to the road surface over the years, increasing the static load by 20%. Another factor was the extraordinary weight of construction equipment and material resting on the bridge just above its weakest point at the time of the collapse. The load was estimated at 578,000 pounds (262 tonnes), consisting of sand, water and vehicles.

Thus, by way of comparison, our steam locomotive and tender were about two-thirds of the "extraordinary weight" contributing to the Mississippi River bridge collapse, but supported only by the pair of rails.

Our steam engine had begun to roll to one side. The engine leaned toward the left and the front dipped down slightly, anticipating the face plant to come. The engine came back up. The left rail bent and tipped outwards.

The locomotive tipped onto its side as 197 tons of fire and water heated to steam, hit the ground traveling a mile a minute. The boiler remained intact and Engineman Dunlap lived to testify.

In constructing the railroad, this section started with a roadbed of gravel, cinders, and black dirt. On average there were 19 fir (wooden) ties per 33-foot steel rail, attached to the rail with a single spike and tie-plate. The rails are embedded in rock ballast, which is tamped down to ensure nothing moves.

To replace the railroad ties, the workmen first removed the spikes holding the rail to the tie. They dug out the ballast so that the old tie could be removed and replaced with a new one.

No. 362 had just passed over 16 rail lengths at speed where 46 ties had been replaced, very few of which were spiked. Nor had the tamping of these ties been completed. They had settled away from the rails because of the trains which had already passed over during construction. The final 9 rail lengths were anything but level.

The final rail, the one that collapsed outward, had all spikes drawn from both ties at the joint connecting it to the prior rail. The spikes were also drawn and the ballast removed from three other ties under the collapsed rail, as well as from the first tie under the receiving end of the next rail onward.

The rail collapsed to the point that its far end left a mark on the railroad tie where the crown of the rail was all the way on its side. The first eight feet of the next rail snapped off as the train careened past the collapsed rail.

One trainman and three passengers died. Seven other passengers were injured. The first passenger car wedged itself underneath the baggage car to its front (Figure 4, "Steel coach after removal from scene of accident").

The trucks (wheels and axles) were knocked off the front of the passenger car, dropping the floor of the car down to the ground level, placing the body of the baggage car on a level with the tops of the passenger seats. All fatalities came from the front of that passenger car.

The full report is in The Railroad Trainman beginning on page 894.

35 Fewer Employees Killed

The railroad handbooks are "written in blood." Every rule exists because someone died. The rule is created or amended to prevent future deaths. The accident investigation concluded that Rule 929 concerning warning flags cannot remain up to the foreman's discretion. The result of this error of judgement was the derailment of train No. 362.

As linked above, the accident report appeared in The Railroad Trainman of July 1913. The same magazine issue (p. 883) includes the article "Safety First, New York Central Lines."

The Safety Exhibit car (Figure 5, "Safety First car"), the latter article reports, was unveiled at the Grand Central Terminal "for the purpose of inculcating the doctrine of 'Safety First' in the minds of our 125,000 or more employees of the railroad."

The Safety Exhibit Car announces that more than ten thousand railroad-property trespassers are killed and injured annually on railroads in the United States. As for its own "Safety First" doctrine, the article triumphantly concludes by noting that on two of the New York Central lines "there were 35 fewer employees killed on duty in only four months after the Safety work was inaugurated."

That leaves me—and surely you—to wonder, "35 fewer than what?"

Immoral Profit Strategies

I am sharing this story because our software is quickly reaching the same point. People will die unless we think of safety first. Criminals create "bot nets" of common Internet of Things (IoT) devices such as DVRs and nanny cams. It's a standing joke that "The S in IoT stands for Security." There is no S in IoT, and there is no Security built into the Internet of Things.

Software professionals recognize the problem, but what can we do about it? Let's look at our currentdangerous—business climate.

Duff McDonald wrote about the Harvard Business School and the Propagation of Immoral Profit Strategies in the April 6, 2017 issue of *Newsweek* magazine.

Harvard Business School's mid-twentieth-century view was that the best type of CEO was one with an enlightened social conscience. Nobel Prize-winning economist Milton Friedman took exception, snidely explaining:

Businessmen believe that they are defending free enterprise when they declaim that business is not concerned "merely" with profit but also with promoting desirable "social" ends, that business has a "social conscience" that takes seriously its responsibilities for providing employment, eliminating discrimination, avoiding pollution and whatever else may be the catchwords of the contemporary crop of reformers. In fact they are—or would be if anyone took them seriously—preaching pure and unadulterated socialism.

McDonald writes that Harvard Business School successfully promulgated this view through professor Michael Jensen:

[He] laid the groundwork for the most radical change in the hierarchy of power in corporate America since the robber barons gave way to professional managers... [teaching the idea that] investors were more trustworthy than managers as custodians of the American corporation. [Jensen] helped a generation of businesspeople lower its opinion of itself and give in to its baser motives... he released CEOs, institutional investors and Wall Streeters from the obligation of considering anything but their own narrow wants and needs.

A generation ago it was common for software professionals to remain with the same company for 20 years. When Thomas Watson, Jr., son of the founder of IBM, retired, IBM proudly stated "for more than four decades, not a single person has lost as much as an hour's work because of a layoff. The basic belief, respect for the individual, permeates all layers of the corporation."

I personally stayed with the same company, Cray Research, throughout the 1980s and 1990s. My career development was within the company context; I had mentors within the company.

We had a formal statement of ethics, but our CEO John Rollwagen put it this way: "What if what you're doing right now... what if it was on the front page of the Star Tribune tomorrow?" He was referring to the local Minneapolis newspaper.

In our "gig economy," mentors can be hard to find. We need to find them, and be them, anyway. Let's continue looking at software development since that's where I live.

Our Code of Ethics

The Association for Computing Machinery (ACM), the world's largest computing society, has a Code of Ethics. The ACM Code of Ethics "includes principles formulated as statements of responsibility, based on the understanding that the public good is always the primary consideration."

The ACM ethics page also links to the "ACM Committee on Professional Ethics (COPE)." That's great, but there is a flaw in this grand system of ethics and social responsibility:nobody cares! Lest you think I'm too harsh, let me tell you another story.

The May 30-31, 1998 Great Lakes Derecho knocked down a large maple tree behind our house. Electric power runs from a pole behind our house, to a pipe sticking out of the house roof, which runs the electric cables down to the circuit-breaker box in the basement. The tree fell across the wire between the power pole and our house. This yanked the guts out of the circuit-breaker box, with the electric cables being yanked upward to the roof as the tree crashed down on top of the wire (Figure 6, "Same Spot Different Storm").

It was a dark and stormy night. The silver maple, after removing our source of electricity, crashed onto the roof above son Jakob's bedroom, leaving Jakob wide awake. This was early morning in the midst of a holiday weekend. We use well water with an electric pump. Two flushes later we were out of water.

Our tree was not the only one to topple that night. Electricians and other contractors were frightfully busy that holiday.

Once our turn came, the electrician took a good look at the 40-year-old panel of circuit breakers. He explained, "I can't touch this unless I first bring it up to code."

Let's think about this in terms of our own jobs. We can easily hear the hypothetical boss's questions. "Can't you just fix it, ship it, and worry about the other problems later? That other stuff wasn't a problem before the error occurred. Fix the error and we'll be right back to where we are. Right?"

What software developer is going to say, "I can't touch this unless I first bring it up to code?" Yet with the electrician there won't be any argument.

I knew that the electrician was answerable to the State of Minnesota rather than to myself. The electrician was responsible for knowing his obligations and responsibilities. The State of Minnesota, in enforcing their electrical code (regulations), removed any choice in the matter.

It's the same with a doctor, lawyer, architect, or carpenter. When he or she states "I can't do that" as a matter of professional ethics or standards, we all accept that. We know such standards exist. *We accept them as binding.*

Do you see the difference? We software developers have no professional standards which the world accepts as binding. Our professional standards do exist. But when the boss says "just do it," nobody thinks twice.

Unsafe Power Imbalance

Sarah Mei, founder of RailsBridge and former director of Ruby Central, writes that most ethics discussions amongst developers conclude that we are indeed obligated to push back against unethical requests (Figure 7, "Be Ethical").

Sarah explains why this does not happen:

Pushing back against a feature on ethical grounds is unlikely to endear you to your managers. It will almost certainly have negative repercussions. Across all disciplines, whistleblowers are more often punished than perpetrators. How well you weather those consequences will depend on your power, formal and informal, within the organization and wider industry. Research has repeatedly shown that gender and racial minorities have less power, both formal and informal, than others at the same skill level. Furthermore, the higher you get into management (i.e., where the unethical request came from), the less likely you'll find minority folks. So while it is not "safe" for anyone to push back against an unethical request, it's extra unsafe for members of gender and racial minority groups. In those cases, you get the power dynamics of race and gender coming into play, in addition to the power dynamics due to org chart position.

Those dynamics inform every part of this, and mean that you are asking a lot more of folks from minority groups when you ask them to refuse. If they have to quit the job to avoid the request, or are fired, folks from minority groups will take longer to find a new job. Statistically, they get paid less and support more people, so they're less likely to have savings. Right now you need to be in an *extremely* privileged place to be able to refuse an unethical request. You need to be senior and have savings. You need to live in a place where alternative employers are plentiful. You need to have a network pre-formed to help find something new. The ability to be ethical should be available to everyone. Using that ability should not disproportionately impact some groups over others.

It's easy to see that my electrician was "protected" by government regulation. Politicians have called for regulating various computing algorithms, but that's missing the point.

What we need is a standard (or oath) that we are allowed and expected to embrace. In essence we as software developers are not beholden to social responsibility. We are beholden to "shareholder value" or the equivalent. There is no universal standard to which society, or our employers, expect us to adhere.

Medical doctors have a Hippocratic Oath and we all accept that. Software developers... not so much.

Some have attributed Silicon Valley's infamous "bro" culture directly to the "wild West" lack of safety regulation. If startups had the safety standards that Detroit is forced to follow, pundits opine, we wouldn't see the wild risks and abuses endemic to both software and culture. We're assuming that regulation has to be imposed from without.

On the contrary. My 1967 edition of The Consolidated Code of Operating Rules names 19 different railway companies on the front cover. The railway companies worked together to regulate themselves.

The U.S. Government did not appear for well over a century of railroading, not until the 1970 "Federal Railroad Safety Act." So, no, the safety standards do not (in theory) need to be externally imposed.

Did the train engineers and conductors get together and tell the railway companies to get it together and regulate themselves? Certainly not!

In fact it was quite the opposite. That Southern Pacific boiler explosion we mentioned, which killed at least 26 people and injured 40 others, happened in the midst of a labor dispute. Photographers from the San Antonio Express newspaper were "roughly handled" by the Southern Pacific's "special police," who also drove other journalists from the epicenter of the blast.

WhatsApp and Signal

The Washington Post in How WhatsApp, FaceTime, and other encryption apps shaped the outcome of the Mueller report reveals:

The use of encryption technology appeared to hinder Mueller in his efforts to uncover dealings between Paul Manafort, who was Trump's campaign chairman, and Konstantin Kilimnik, a Russian Manafort worked with who U.S. officials believe has connections to Russian intelligence. ... Of course, encryption systems are only as effective as the people who use them. When Mueller charged Manafort last year with witness tampering, filings showed that investigators had been able to read his encrypted WhatsApp messages because the app—which allows users to back up messages into online storage—had saved them to his iCloud account.

The Senate Intelligence Committee's longtime director of security, James A. Wolfe, pleaded guilty last year to lying to the FBI about using encrypted messaging to speak to reporters during a federal leak investigation.

Wolfe's use of Signal would have prevented anyone else from seeing the messages in real-time—but the app does not delete messages off users' smartphones if they don't activate the "disappearing messages" function.

Investigators didn't say how they saw the messages, but they could have seen them in full just by looking at Wolfe's government-issued phone. The indictments, citing Signal messages, included direct quotes.

Do apps well suited to criminal activity pose ethical concerns for the developers who design and create them? Perhaps they do! I would pose the same question for surveillance apps such as location trackers or facial recognition or private-data-sharing apps. In fact I would pose the same question for tech giants built on these premises such as Facebook, Apple, and Google.

Walk Away?

Train wrecks are such spectacular disasters that the term has come to informally mean "a chaotic or disastrous situation that holds a particular fascination for observers." We don't see software train wrecks as literal train wrecks—yet. Software controls so much that it can soon come to that.

We as software developers have neither the power nor the protection of anything like the Hippocratic Oath. Yet, powerful or not, we do carry the social responsibility. No purveyor of any "Software Engineering Code of Ethics" legally has our back. I'm looking at you, ACM.

What can we as software developers do? Nothing. Not a thing!

Oh—wait—yes we can. We can walk away. Leave the industry. Now that is an interesting thought... has anyone noticed the lack of women in technology, which is quite recent, and that departure has not affected the other STEM fields? It's almost like a lot of smart people are done.

Back when there was such a thing as corporate responsibility, and it was ** a shareholder value, at Cray Research we had a large proportion of women in all positions and levels. We split our women's teams across two aircraft lest one go down. Certain all-women teams were that ** important.

Instead, we now have cases like a Missouri-based drugmaker explaining that the company has a "moral requirement" to gouge the public to the greatest extent possible .

In an interview, Normal Mulye, Nostrum chief executive, said he had priced the product according to market dynamics, adding: "I think it is a moral requirement to make money when you can ... to sell the product for the highest price."

He also defended the actions of Martin Shkreli, who became infamous in 2015 for his decision to raise the price of an Aids and cancer drug from $13.50 to $750 per tablet. Shkreli was jailed earlier this year [2018] on unrelated fraud charges.

"I agree with Martin Shkreli that when he raised the price of his drug he was within his rights because he had to reward his shareholders," said Mr Mulye.

Fortunately, the same article notes, the U.S. Food and Drug Administration (FDA) pushed back:

In a tweet responding to Mr Mulye's comments, Scott Gottlieb, FDA commissioner, said: "There's no moral imperative to price gouge and take advantage of patients. FDA will continue to promote competition so speculators and those with no regard to public health consequences can't take advantage of patients who need medicine."

The Silicon Valley tech giants will, no doubt, continue to remain as amoral as possible. We have a power imbalance between the employees and contractors, who might prefer to be ethical and moral (and physically safe), and the companies themselves who have other priorities.

Be careful out there.

Summary

We took the long way around to place our current ethical situation in perspective. Our U.S. corporations have become amoral, and this is a relatively recent development smacking of the tycoon and robber baron days of the late 19th Century. When it comes to ethics, morality, privacy, or safety concerns, nobody has our backs as software developers. That fact does need to change.

When we hear about "antitrust" or "anticompetitive" concerns in the news, that sounds lame. But we now know that's how the tycoons and robber barons were torn apart. The FDA commissioner used the phrase "promote competition" as a response to price gouging.

The U.S. Department of Justice (DOJ) broke apart John D. Rockefeller's Standard Oil Company to promote competition in the landmark 1911 U.S. Supreme Court case Standard Oil Co. of New Jersey v. United States . The landmark 1958 decision in Northern Pacific Railway Company v. United States relied on that Standard Oil decision in declaring the Northern Pacific Railway's practices anticompetitive. DOJ now references Northern Pacific in considering "big tech" anticompetitive.

Northern Pacific notes that "price fixing; division of markets; group boycotts; and tying arrangements" are all illegal. That could be what's meant when the FDA says "promote competition." The FDA isn't merely whining or complaining; more likely, it's building a case. Thus be assured that any low-key references to the Sherman Act, such as "promote competition," carry enough power to bring Big Oil, Big Tech, and indeed Big Pharma, to heel.