by Melissa Dark

Steve Blouin is a lead software engineer for Database Solutions, a large multinational company that designs and develops custom software for a variety of private and public clients. For the past five years, Steve has been the lead engineer on a software project for Identification Information Systems (IIS). IIS, one of Database Solutions largest clients, is an IT service provider to over 40% of the Motor Vehicle Branches in North America. IIS performs a variety of tasks including articulating software specifications, managing software development projects, overseeing IT installation projects, and systems maintenance.

As the lead software engineer on the IIS project, Steve is responsible for a software development team of 4 other programmers. Up to a year ago, the team included 5 programmers. Last year Lloyd Johnson was laid off as a result of some restructuring at Database Solutions. Lloyd enjoyed working for Steve and over the last four years they had become friends. They hiked together and often got their families together for cook-outs, movies, and other recreation. That was up until the time that Lloyd was laid off. Since the layoff, Steve and Lloyd had not seen much of each other. Their once solid friendship had become strained. The last time Steve called Lloyd, Lloyd told him that things were tough and he preferred that Steve not call to find out how his job search was going. Lloyd had been out of work for four months and might have found employment much quicker if his family had been willing to move. However, his mother-in-law’s health was not good and the primary responsibility for taking care of her rested with his wife, so his family elected to stay in the area.

The layoff was no fault of Lloyd’s. Lloyd was a good programmer and did his job well. However, he was the least senior member on the team. Unfortunately, Database Solutions lost $1.8 million of business they had held for many years. The loss of the contract meant that 30 employees were laid off, of which Lloyd was one. To this day, Steve vividly remembers sitting in the conference room with his boss, Richard Emmons, and Lloyd. Richard is the division manager responsible for engineering. Richard oversaw 6 other development teams besides Steve’s with a total a staff of 65. Steve had worked for Richard for several years and had come to know that, for Richard, it was all about the bottom line. Richard is well-known for ensuring that every project have a profit margin of 37%. On April 3, Richard emailed Steve to request that he and Lloyd meet with him at 3:30 in the conference room to discuss the IIS Solutions reeningeering project. Based on the chain of events with the IIS project, Steve figured that Richard had bad news.

Indeed, Richard did have bad news. IIS had decided to pull 60% of their new contracts from Database Solutions and take them elsewhere due to a glitch in some software that had surfaced in January. On January 12, a Texas citizen named Howard Smith, was pulled over while driving with a burned out tail light. The strange thing about the whole situation was that when the patrol officer went to check Howard’s registration in the system, there was no record of Howard Smith having registered his vehicle in Texas and furthermore, there was no evidence that Howard Smith existed. This was the tip of the iceberg. Over the course of the next three weeks, 324 people lost their identities - that is to say, within the Texas system, there was no evidence that these individuals existed.

The Bureau of Motor Vehicles spent several thousand dollars investigating the problem over the next month. In February they called a meeting with IIS executives to let them know that they pinpointed problems in the software that led to the incident. IIS then started its own investigation. The outcome of the investigation was two-fold: Database Solutions lost 60% ($1.8 million) of the IIS business and in order to hang on the remaining 40%, Database Solutions would need to fix the software. In the meeting on April 3, Richard laid off Lloyd, citing the loss of contracts to IIS. Richard also notified Steve that the software error needed to be fixed immediately and permanently. It was clear that there could be no further problems with the software or it would mean the loss of additional business and the termination of other individuals. Richard’s parting words to Steve were “This needs to be fixed right and right away if IIS is to continue employing the members of your team, including yourself. There are a lot of people counting on you Steve, including myself.”

Unfortunately, Steve knew it would be virtually impossible to guarantee Richard and IIS that the software would never malfunction. Not that it would impossible to reengineer and error proof the code, just that it would be difficult to do with the limited resources that Richard had authorized. Steve knew that asking his team to work day and night with no overtime to come in under budget, but he also knew he wanted to guarantee IIS that they and the citizens of Texas would not be faced with a similar ordeal ever again.

1. Identify the problem(s) in this case?
2. Discuss these problems from the perspective of Steve, Richard, Steve’s software team, IIS, and the citizens of Texas.
3. What are the respective rights of Steve, Richard, Howard, and IIS?
4. Who is responsible for the results of a software program?
5. Has Steve acted responsibly? Explain your answer.
6. Has Richard acted responsibly? Explain your answer.
7. Has IIS acted responsibly? Explain your answer.

Case Overview

This case involves three main characters (Steve, a software engineer, Lloyd, a laid off software engineer, and Richard, a division manager) and one minor character (Howard Smith, a Texas citizen whose identity was lost in the bureau of Motor Vehicles IT system). It also involves three organizations (Database Solutions, the software development company, IIS, a national IT service provider that hired Database Solutions to develop software), and the Bureau of Motor Vehicles (a client of IIS and the ultimate client of the software). The case presents a snapshot of a problem. The problem is that a software bug resulted in 325 Texans incurring a loss of identity in the Texas system. As a result of this problem, Database solutions has lost a majority of its business with IIS and is under the gun to fix the error in order to retain the remaining business.

Case Objectives

After analyzing and discussing this case, the students will be able to:

• Identify the problems in the case
• Discuss these problems from the perspective of Steve, Richard, Howard, Database Solutions, IIS, and the Bureau of Motor Vehicles
• Analyze accountability from various perspectives
• Identify potential root causes that contributed to this problem
• Identify potential solutions
• Analyze the impact of software
• Discuss the need for regulations, standards, guidelines, procedures in software engineering

Debriefing Guidelines

The case is designed to bring the real life problems to the classroom so that students can be aware of ethics and professional issues in their profession. This case can be facilitated in a variety of ways. Described here are two methods that I have found most effective to date.

Method #1:

Step 1:

Begin with a group discussion using questions 1-4 at the end of the case. This helps bring to bear the details of the case and the events. When asked to identify the problem in the case, students will tend to cite the obvious. The most frequent response is that the software had an error. The students needs to be encouraged to explain why this is a problem, for whom it was a problem, and whether or not the persons or organizations in the case could have a right to expect reliable software. Questions 2-4 are intended to solicit answers to these more detailed questions.

Step 2:

Ask students to contemplate question #4 individually. Ask them to write their response to questions 4 on a piece of paper. Note, students might identify more than one party that is responsible. Encourage them to list their response in order of most to least responsible. Then have them share their thoughts with the class. When I have used this technique, students either tend to gravitate toward a hierarchy of the individuals in the organization who should be held responsible or towards the organizations themselves. For example, some students identify various persons (the software engineer, the division manager, the software testing team, etc. ) at Database Solutions that should be held accountable, while other students feel will assign responsibility to Database Solutions, IIS, and the BMV for various tasks. This is a great lead in to talking about different types of controls that could, should, or might be considered to assure the quality of software products.

Step 3:

As a follow up to step 2, I split students into small groups (3-6 students per group) and ask them to brainstorm and document the following:

What types of controls should an organization have in place to control the quality of their employees work?

What types of controls should the industry have in place to assure the quality of an organization’s product?

Step 4:

Step three usually leads to a discussion of varying levels of control depending upon the type and characteristics of the software and consequences of malfunction. If you want, you can conclude by having the students develop a taxonomy of types of software, level of control needed, and a rationale for their decision. They can do this in narrative or in a chart like the one below:

Method #2:

Step 1:

Begin with a group discussion using questions 1-4 at the end of the case. This helps bring to bear the details of the case and the events. When asked to identify the problem in the case, students will tend to cite the obvious. The most frequent response is that the software had an error. The students needs to be encouraged to explain why this is a problem, for whom it was a problem, and whether or not the persons or organizations in the case could have a right to expect reliable software.

Questions 2-4 are intended to solicit answers to these more detailed questions.

Step 2:

In small groups (3-6 students), have students identify all potential contributing factors. Have them document their work on a fishbone diagram. Below is one example of a fishbone diagram that a group of students produced.

Step 3:

Have the groups present their fishbone diagram to the entire class and discuss. This is valuable for students to see each others’ work to validate their own thinking and to see what they might have left out.

Step 4:

Again in small groups, have them identify two or three of the biggest problem areas and discuss what countermeasure should be in place to address these problems. Have the students present their conclusion to the class.

Step 5: Again, this usually leads to discussion of methods of control. Use step 4 from method 1 above or discuss this as a group.