Showing posts with label software engineering. Show all posts
Showing posts with label software engineering. Show all posts

Monday, July 29, 2019

What Price Safety? The 737 Max 8 Saga Continues


In March and April, I blogged on the tragic and costly software problems plaguing Boeing's 737 Max 8 jetliner.  Briefly, after two crashes in Ethiopia and Malaysia in which a total of 346 people died, evidence pointed to a software problem in the fly-by-wire plane, and the U. S. Federal Aviation Administration (FAA) grounded the plane after numerous other nations did the same in March.  In May, Boeing claimed that they had fixed the software problem, and since then Boeing and the FAA have been running extensive tests to verify that the problem has in fact been solved.  On June 3, Boeing CEO Dennis Muilenberg said that he expected the FAA to declare the plane flightworthy by the end of the year, but declined to give a specific timeline. 

In the meantime, all 387 existing MAX 8s are sitting on the ground instead of flying and generating revenue for the airlines that own them.  This has caused big headaches for both American Airlines and Southwest, which recently announced that it is terminating service to New Jersey's Newark Airport simply because it doesn't have enough planes owing to the MAX 8 groundings.  And American's losses are running in the range of $400 million, largely due to the groundings.

Most of the time, when software fails to do what it should, the consequences are fairly minor.  If it's one feature on some software on your laptop that acts up, maybe you lose some work, or even get so turned off by the problem that you swear never to buy that software again. But you remain healthy and nobody dies.

Then there's the whole issue of software security, and making sure malevolent attacks don't disable or otherwise inconvenience users.  Software companies are used to dealing with such things by now, and generally stay up to date with patches that prevent hackers from doing major damage, as long as the users install the patches.

These kinds of environments are what most software developers are used to working in.  The bigger the organization and the more critical the software, the more bureaucracy is involved, but that's not necessarily a bad thing.  I spoke with a software engineer many years ago who worked for a regional telecommunications company.  She told me that she'd been spending most of the previous year on changing exactly one line of code.  The reason it took so long was that a bunch of other engineers had to take that change and try it out in all sorts of other situations and find out what its ramifications were, and whether it would cause problems down the road. 

Telecomm companies are rather shielded from competition, and so taking a year to change one line of code may be fairly routine, I don't know.  So maybe we shouldn't be that surprised if it now takes six more months for the FAA to make sure that the changes Boeing has made in their 737 MAX 8s are really going to make things better and not otherwise. 

Thing is, the phone company didn't have to shut down and wait for my software engineer friend to finish her job.  But when software is intimately tied in with a multimillion-dollar piece of hardware that you can't use just a little of, and the software makes the whole thing unusable, it creates a spectacle that we haven't seen since the week or so after 9/11/2001 when all domestic U. S. flights were grounded.  And that period, plus the general fear of flying it engendered, hit the airlines with an economic punch that took them years to recover from.

Fortunately, the MAX 8 problem doesn't appear to have frightened people away from flying in general.  Because of the scarcity of seats, the airlines have been able to charge more, and so revenues at American and Southwest are actually up, despite the shortage of planes.  Nevertheless, Boeing has set aside nearly $5 billion in case it ends up having to pay its customers for loss of revenue, and lots of airlines around the world are going to think very hard before they place any more orders with Boeing.

Unlike mechanical failures, software failures are not simply a function of physics.  Software is so dynamic and dependent on the exact conditions and history of its environment that it is virtually impossible to "prove" it won't fail under any circumstances, except in rare and rather academic cases.  Some day, I hope the whole history of this fiasco will come out, as it will be a fascinating study in how software engineering ethics failed in this instance, and it will harbor lessons for how safety-critical software should not be written. 

The problem with such a story may be that it could be too hard for anybody except specialized software engineers to understand.  But then again, it may boil down to management problems, as so many ethical issues do.  Already there has been speculation that the FAA was allowing Boeing to conduct too many of its own safety tests, and basically just taking Boeing's word for it that everything was okay.  Only when we have enough details about how the problems happened and how they were fixed, can we judge whether the FAA has been lax or negligent in this area.

In the meantime, software engineers everywhere except Boeing can be glad that their work is not going under the microscope of the FAA's inspection.  But there are plenty of other types of software that are life-critical:  for example, software for medical devices, automotive software, even the software that lets first responders communicate with each other.  A failure with any of these products can have life-threatening implications. 

So maybe the lesson here for software engineers is:  program as though your life depended on it.  If more programmers had that attitude, we'd all have much better software.  Maybe not so much of it, but that might not be a bad thing either.

Sources:  The report describing CEO Muilenberg's comments appeared on the CNBC website on June 3, 2019 at https://www.cnbc.com/2019/06/03/boeing-plans-to-fly-a-boeing-737-max-certification-flight-soon-ceo-says.html.  Reuters reported on Southwest leaving Newark at https://www.reuters.com/article/us-american-airline-results/boeing-737-max-groundings-plague-u-s-airlines-frustrated-southwest-exits-newark-idUSKCN1UK1N5.  I also referred to the Wikipedia articles "Boeing 737 MAX" and "Boeing 737 MAX groundings."

Monday, February 29, 2016

Happy Friendship Day—Not

Facebook is the quintessential dot-com success story:  young guy invents software in his dorm room that ends up creating an entire industry and making him a storied billionaire, besides becoming a significant part of the social lives of over a billion people worldwide.  Ethically speaking, on the face of it Facebook looks like a no-brainer:  it's all about connecting people, right, so what can go wrong with that?  Well, plenty, as shown by stories of flaming mobs and online bullying leading in some cases to suicide.  But besides these more spectacular crimes and misdemeanors caused by the general cussedness of humankind, there are things that the software developers do themselves which can go awry.  And here's where it gets personal—very personal.

Back in January, Facebook founder and CEO Mark Zuckerberg called for people to celebrate Feb. 4, the twelfth anniversary of Facebook's founding, as "Friendship Day."  Now Mr. Zuckerberg is free to call for anybody to celebrate anything, and I have no problem with that.  The trouble came, at least in our case, when some anonymous software engineers at Facebook had a bright idea inspired by the call and, as software engineers often do, put it into action without telling the users what they were up to in advance. 

It was simply this:  "Hey, why don't we take some pictures that people have posted in the last year or two and send the pictures to them along with a greeting like 'Happy Friendship Day'?  What could be wrong with that?"  As it turns out, plenty.

Zuckerberg himself is only 31, and it's likely that the average age of the technical staff at Facebook is somewhere around that number.  If you are a well-paid employee of a giant software successful software company, death does not occupy a large part of your personal horizon.  You know it's out there somewhere, and you read about it online with the other bad news, but it's not likely to have affected you personally to a great extent, except perhaps for some old relatives whose funerals you may have attended out of a sense of duty. 

It turns out that in the last two years, my wife, who is 59, has lost five relatives of various degrees of closeness, ranging from a cousin she hadn't seen in years to her last remaining aunt, her sister, and her father.  And in the last few years she had taken pictures of these people, and posted many of the pictures on Facebook at appropriate times.  You can tell where this is going.  Imagine how she felt when a couple of weeks ago, she logged on to Facebook one day and saw under the headline, "Happy Friendship Day" a photo of her father in the hospital during his final illness.  He died almost exactly a year ago.

For the better part of a day, it was like walking on eggs around here.  She rarely gets truly angry, but if Zuckerberg had happened to stop by our house that day, he might have come close to a personal encounter with mortality that he would never forget.

A short time later, she spent several hours systematically taking down every single photo she had ever posted on Facebook that included anyone who has since died.  It was a lot of pictures, but she was determined that the machine was never going to catch her by surprise that way again.

Sometimes I amuse myself by imagining how I would explain various modern technologies to someone transported through time to the present from, say, fifty or a hundred years ago.  Although Facebook shares some features in common with things that existed in 1966—photo albums, high school annuals, and the postal system, to name three—you could not express what it does simply by referring to those things.  And the main feature that would be missing from that description is the way Facebook manipulates the rules, and what happens to your Facebook stuff when they play games with it like Happy Friendship Day. 

Unless you happened to be living in the 1960s with a busybody aunt who lacked any sensitivity to your feelings, I can't imagine someone back then receiving a customized photo album labeled "Happy Friendship Day" that contained pictures of some of the most intimate and painful times in your entire life.  But that is exactly what Facebook did to my wife.  At least if a nosy aunt did such a tacky thing, she'd be standing right there where you could chew her out for it.  As it is, though, the faceless System of Facebook is all she can blame, and her only defense against further manipulations of this kind is to withdraw any possibly pain-evoking images from the System so it can't fool with them. 

Once my wife explained to me what had happened, in the heat of the moment I thought that whatever numskull came up with that idea ought to be tied to a chair and made to watch 200 hours of cat videos.  I now think that is excessive.  But certainly, some live person or persons originated the idea of recycling pictures for Happy Friendship Day, and as Zuckerberg himself has expressed enthusiasm for artificial-intelligence solutions even to programming problems, it's virtually certain that some algorithm the programmers wrote made the selection of which photos to include.  Despite the best programmers Zuckerberg's money can buy, that algorithm did not have feelings, and it was therefore insensitive to the psychic pain that such actions could cause. 

We are in a strange time in which former organizational divisions of all sorts are falling down, and people who were trained to do one kind of work—software engineering, say—find themselves doing very different kinds of work—for example, manipulating on a massive scale items that have deep and powerful personal meanings for literally a billion people or more.  There is an old saying, "Fools rush in where angels fear to tread."  It would have required the discretion and intelligence of many angels to select only those pictures which would have been appropriate to accompany a message such as "Happy Friendship Day" for each one of Facebook's users.  Unfortunately, software is a poor substitute for angelic insight, and the result was in many cases foolish, or worse than foolish. 

For reasons of time and disinclination, I have no Facebook page, other than possibly a dormant one my wife started for me in connection with a book publication.  If anything happens on Facebook that she thinks I need to know about, she'll tell me.  It has had its good moments for her, and we have reconnected through it with people around the globe whom we had lost touch with.  But in the case of Happy Friendship Day, Zuckerberg blew it, at least where my wife is concerned.  And it's going to be a long time before she posts personal pictures on that site again.

Sources:  I referred to an item carried by the Indo-Asian News Service (and no doubt many other outlets) on Mark Zuckerberg's announcement urging people to celebrate Facebook's twelfth anniversary as Friendship Day.  The article appeared at http://www.ndtv.com/offbeat/celebrate-facebooks-anniversary-as-friendship-day-mark-zuckerberg-1265232.

Monday, October 28, 2013

The Obamacare Website Rollout: Not What the Doctor Ordered


Software failures can have all sorts of bad consequences, ranging from minor annoyances up to and including death.  On that scale, the very public problems that people currently run into when they try to use the Affordable Care Act's website to buy federally-mandated insurance are somewhere in the middle.  (Since President Obama is on record as having no objection to the term "Obamacare" for the Act, I will use it too from this point on.)  To my knowledge, no one has yet died as a direct consequence of not being able to use the site.  But on the other hand, it's hard to think of another software-related issue that has garnered so much negative publicity in as short a time.  While there is plenty of blame to go around, the question I'm interested in today has to do with the ethics of software engineering, and what lessons this debacle can teach us along those lines.

Software engineering is a relative latecomer to the engineering fold.  There were only a few dozen programmable computers in the world as late as 1950, and the first U. S. undergraduate programs in software engineering were not accredited until 2003.  But few types of engineering involve the average non-technical customer more directly than the design of high-volume websites, which requires strategic and organizational planning as an essential aspect of the overall process. 

According to published reports, the rollout of the www.healthcare.gov website was something of a rush job.  For political reasons, the Oct. 1 deadline could not be postponed, and many changes were being made right up to the last minute.  Finally, there was little time for beta testing with a small group of friendly and informative users who could find problems in time for them to be fixed before the main rollout. 

I am glad I was not one of the people who worked on this website, but I can sympathize with them.  My last major engineering job before deciding to go back to school for my Ph. D. was with a firm that wanted to make cable boxes, the little thing that sits on (or now, under) your TV and selects channels.  The company had never made a large-volume consumer product before.  Up to that time, most of their customers were military and scientific users who paid plenty for a few hand-crafted instruments.  Despite the best efforts of our engineering team, the new box never worked right.  At one point I had a conversation with an older engineer who said, "I'm looking at your group and what I see is a bunch of trapped engineers."  I later learned that the company ended up recalling all the boxes from the field at a cost of six million dollars.  By that time, I was in grad school and dealing with problems of a different sort.   

Sometimes, engineers are placed in an impossible situation where even Superman couldn't deliver the goods as requested, and minimizing damage is about all you can do, at least to start with.  The Obamacare website was a large and complex project that everyone knew would both receive tons of traffic from all sorts of people, most of them technically unsophisticated, and would also draw intense media attention, much of it potentially hostile.  If it had been up to the software engineers, the project might have been "frozen" (no more major changes allowed) up to a year in advance of Oct. 1, and early versions would have gone through beta testing with larger and more varied groups of test subjects with plenty of time to work out the glitches before launch. 

Obviously, that didn't happen.  At the risk of sounding biased, I will state here that the way this project was carried out seems to reflect a mindset which is evident in other actions of the Obama administration.  The President and a circle of powerful like-minded people in the administration have a set of ideas which they all agree on as The Way Things Should Be.  Philosophically, they are idealists in the sense that they start with ideas, and then try to make reality conform to their ideas.  Evidently, the political people in charge of implementing Obamacare were coming up with more ideas for the website right up to the time that it was turned on, and disregarded the hard engineering realities of designing a website that must handle many millions of users who are faced with a fine if they don't sign up for insurance through the site by the end of the year. 

The problem with philosophical idealism is that it sometimes collides with reality, and in such collisions, reality always wins.  In such encounters, idealists may or may not learn the error of their ways.  Of necessity, they end up doing what reality requires them to do, but often in a way that is inefficient, expensive, and more trouble than otherwise.  A new deadline of November 30 has just been announced as the day by which www.healthcare.gov will be working.  Jeffrey Zients, the Chief Performance Officer of the United States, is now in charge of fixing it, and has declared publicly that "Healthcare.gov is fixable."  Any system that is not physically impossible is fixable given enough time and resources, but only time will tell whether Zients and his underlings can get the repairs done on time.

But the rocky startup has added more fuel to the fire of ill feeling that the U. S. public in general harbors toward the federal government.  In a poll by the Pew Research Center for the People and the Press released last week, only 19% of those polled said that they trust the government in Washington to do what is right just about always or most of the time.  Before about 1970, most people did have such trust, but the trend since the early 1960s has been downward, falling below 50% around 1973 (the peak of the Vietnam War) and has risen above 50% since then only once:  right after 9/11/2001 and the first war in Afghanistan.  The fact that most people in the U. S. no longer think that their government can be trusted in this way goes beyond partisan politics to signal deep structural problems in the way power is allocated and used.  This is much more than a problem in engineering ethics, but engineers have to deal with it like everyone else.  And those working on www.healthcare.gov bear a particular responsibility to exhibit leadership in the days to come.

Sources:  An article published online on Oct. 25, 2013 by Robert Pear and Sharon LeFraniere at http://www.nytimes.com/2013/10/26/us/politics/general-contractor-named-to-fix-health-web-site.html describes Jeffrey Zients's statements about the proposed repair of www.healthcare.gov by Nov. 30.  I also referred to the Wikipedia article on Jeffrey Zients.  Information on the history of accredited software engineering programs was taken from Chapter XIII, "Software Engineering Accreditation in the United States," by J. McDonald, M. J. Sebern, and J. R. Vallino, in Software Engineering: Effective Teaching and Learning Approaches and Practices, H. Ellis, S. Demurjian and J. F. Naveda, (eds.), Information Science Reference, 2008.  The statistic on public confidence in the U. S. government was published online by the Pew organization at http://www.people-press.org/2013/10/18/trust-in-government-nears-record-low-but-most-federal-agencies-are-viewed-favorably/.