The Dark Side of Software Engineering

Evil on Computing Projects

Johann Rost, Robert L. Glass

• Editore: Wiley-IEEE Computer Society Pr
• Anno: 2011
• ISBN:
  9780470922873
• Edizione: 1
• Argomento: Business
• Categoria: Business Ethics

Betrayal! Corruption! Software engineering?

Industry experts Johann Rost and Robert L. Glass explore the seamy underbelly of software engineering in this timely report on and analysis of the prevalance of subversion, lying, hacking, and espionage on every level of software project management. Based on the authors' original research and augmented by frank discussion and insights from other well-respected figures, The Dark Side of Software Engineering goes where other management studies fear to tread -- a corporate environment where schedules are fabricated, trust is betrayed, millions of dollars are lost, and there is a serious need for the kind of corrective action that this book ultimately proposes.

Part 1: DARK SIDE ISSUES

You have just finished reading our introduction to our dark side book. We have told you what we mean by the dark side, why we chose to write about it, how prevalent it is, and who else is talking about it. And we shared with you some personal anecdotes about our own experiences with dark side matters.

We also pointed out that, although we’d like to say some generic things about these dark side issues, in fact it is nearly impossible to do so. All these dark side issues have some things in common—they are all evil manifestations of computing behavior—but on the other hand, they differ enormously in how often they occur and what they are about.

It’s high time, at this point in our book, that we stop waving our hands about these dark side issues, and get down to brass tacks about them. In the seven chapters that follow this introduction to Part 1 of our book we get very specific about each of these matters. Welcome to the many-faceted worlds of subversion, lying, hacking, theft of information, espionage, disgruntled employees and sabotage, and whistle-blowing. We hope you will find it as fascinating to learn about those issues as we did.

CHAPTER 1

SUBVERSION

We use several approaches to explore subversion. The first section covers case studies and examples of subversion on software projects; the background information for the material is drawn from the computing and popular press. In the second, and longest, section of this chapter, we present the findings of our unique research survey, one in which we surveyed practitioners to determine how often subversion happened in the software world, and in what ways. We are particularly proud of this section, in that we present the results of exploring a major topic in the field of computing and software that no one else has explored. (An abbreviated version of this material was published earlier in a leading computing journal). Finally, in the third major section of the chapter, we present the hitherto unpublished results of a follow-up survey, one in which we asked responders to the first survey for additional input.

Now, on to the case studies.

1.1 INTRODUCTORY CASE STUDIES AND ANECDOTES

Some Motivational Examples.

A sprinter is preparing to break a one-hundred-meter record. During the race someone on the edge of the track disturbs him by throwing pebbles at him and holding up funny pictures. The sprinter’s chances of breaking the record are diminished because of the distractions. If the person who is causing the disturbances is an experienced sprinter himself, he might do it in a more sophisticated way—for example, tens of seconds before the official start he might imitate the sound of the starting signal. The sprinter is thus likely to fail in breaking the record and, what is more, he may even fail before the start of the race. The analysis of the failure of the project concludes the following: “Study after study reveals that sprinters have the most problems in the fractions of a second around the start, that is, at the very beginning of the race” (also known as the “requirements phase”!).

Such a situation in sports verges on the ridiculous. However, it happens quite frequently in software projects. A great number of software projects involve people who wish the project to fail. How is this possible?

1.1.1 A Faculty Feedback System

A college wanted to introduce an online system that allowed students to give anonymous feedback to their teachers. The feedback system was intended to provide an outlet for the evaluation of the quality of lectures and even reveal possible problems. It was hoped that, in the long run, the system would help to identify ways to improve the average quality of lectures.

A superficial analysis revealed three stakeholder groups: the students, the professors, and the college management. The students and the management supported the planned system for obvious reasons: The quality of the lectures and thus the reputation of the college were expected to improve through this project. In theory, both the students and the management would benefit from increased influence; the management would have gained access to additional ways of control. The students were concerned, however, that the anonymity could be broken one way or another, resulting in potential disadvantages for students who had given negative feedback.

A broad consensus of opinion indicated a concern that the feedback needed to be secured against potential manipulation. To prevent the possibility of results tampering by the students, each student was provided with only one opportunity to vote for each lecture. The chances for a very angry student to submit the same negative feedback more than once (thus dramatically lowering the average evaluation feedback for that particular lecture) were reduced. To prevent the possibility of a pro­fessor illicitly tampering with the system (for example, giving excellent feedback to his own lecture by pretending that he was a student), other safety measures were introduced. The system had to prevent all these kinds of potential manipulations of information. However, the aspect of protection against falsification required some authentication, which could be a conceptual conflict to the prerequisite of anonymity.

The professors’ responses were multifaceted and therefore required further analysis. Some professors who were well known for their outstanding lectures welcomed the plans for the feedback system enthusiastically for quite obvious reasons: They expected excellent feedback for their lectures. Officially, there was no connection between the students’ feedback and the career opportunities of the professors. It was obvious, however, that continuous good feedback would be taken into consideration if a higher position in the college management became vacant.

Other professors were more reluctant about the feedback system. Some teachers bore the responsibility of teaching difficult (and mandatory) lectures such as math. Since these lectures were known to be unpopular with many students, the teachers expected negative feedback: Even an excellent lecture of this type (for example, in statistics) would never get feedback as good as a “special interest group” lecture in which only students who are fascinated with the topic participate.

Additionally, some teachers, who were running a small consulting business in addition to their teaching duties, were concerned that the feedback system might force them to spend more time preparing the lectures, something that could eat into their time for professional engineering consulting. This college allowed additional consulting income as long as the teaching duties were not affected. However, this type of sideline was only tolerated but not fully accepted.

Other teachers had secret concerns that the feedback system could reveal deficiencies in their teaching abilities. These teachers feared they might be unable to solve the problems fast enough (or worse, might be unable to solve these problems at all); the teachers had serious concerns about the negative impact of the feedback system on their careers. Some teachers even advocated the cancellation of the project system plans due to the anticipated negative impact of the system on the working atmosphere among the professors, in addition to their concerns about possible data misuse. Most professors, however, kept their opposition secret, hoping that the project would fail or that the topic (an online feedback system) would simply disappear from the agenda one way or another.

After the project was under development, a growing discussion arose around the issue of who “owned” the data and what would be done with the results. The students were of the opinion that student representatives should administrate the data. They claimed that the feedback was given by students and that for this reason the students are the legitimate “owners” of the data. Moreover, the students suggested that all results should be made public automatically. The teachers were not particularly fond of this idea. Publishing the results in an automatic way implied certain risks, particularly if the results were very negative. (For example, if the system was manipulated, it would be difficult to completely rehabilitate the reputation of the [unjustly] denounced teacher.) The results could be borne out of methodical weaknesses—that is, if only one or a few students provided feedback for a certain lecture, these few opinions might be negative even if the lecture was, in reality, more or less okay. However, in certain cases where the lecture was really poor and the negative feedback was more than justified, the college management would have a more efficient way to solve the problem (rather than pillory the particular teacher). It became clear that negative results would need further analysis and that the decision to stop the automatic publishing if necessary should be placed under human authority.

Some teachers suggested that the results should be accessible only to the professor whose lecture was given feedback. Others suggested that the results should be accessible to a committee consisting of professors, management, and perhaps students. The committee would analyze the results and decide what should be done with them. But here were disadvantages to this solution. For example, if this committee had exclusive access to the data, some of the professors (i.e., the members of the committee) would have had access to very delicate information about other professors (i.e., their colleagues). This knowledge would give them additional influence and power. The shift of power might prove to be a disadvantage for the “group dynamic” of the college.

Then, a prototype of the system was presented publicly at the college. The meeting was meant to encourage decision making regarding the fate of the project and whether it should be continued or not. During the presentation, it became completely clear that a large group of professors were totally against the project and wanted it cancelled (perhaps even the majority of professors shared this sentiment). This group, however, did not have enough of an argument against the system. That is, they did not have enough of a legitimate argument. Of course the professors had more than enough (secret) reasons to wish for the cancellation of the project. Those reasons, however, could not be brought into discussion—the reasons had to do with the sideline consulting business.

So this group of opponents changed their strategy: They did not try to cancel the project anymore. Instead they tried to destroy it. Notice the subtle but important difference between “cancel” and “destroy.” When a project is “canceled,” an authority decides that the project will be discontinued. Usually this decision requires logical reasons that are considered legitimate in the particular group. When a project is going to be “destroyed,” the project goes on—at least for the time being. The subversive stakeholders, however, try to influence the project in a way that finally leads to its failure (usually for “technical reasons”), thus enabling them to keep their true motivation secret. Unlike a “cancelled” project, a “destroyed” project (which “fails” for allegedly technical reasons) does not require any additional arguments to be discontinued.

The group of professors who were against the project followed the above-mentioned subversive strategy: When it became clear that they (the group of professors) could not bring the project to a halt by using political arguments, they apparently “accepted” that the project would continue. From this moment on, the political discussions seemed to fade away in the background. But by making various suggestions, they tried to influence the project in a way that would finally cause it to fail, that is, be terminated for technical reasons. The discussion was centered on purely technical decisions. (Nevertheless, the opposing group of professors never lost the desire to stop the project.)

The Achilles’ heel of the project was the conceptual conflict between the anonymity of the feedback and the security against manipulation. The resolution of this problem would require non-technical processes (that is, processes that happen on paper, not in software) and trusted individuals who could mediate negotiation and compromise on the part of all responders. But the opposing group of professors rejected all possible solutions for various reasons. Officially, the reasons were based on purely technical arguments. Unofficially, the group of professors just did not want to proceed with the project, hence the rejection of all possible solutions.

Using entirely technical arguments to achieve a political goal is highly conspicuous in many projects. Subversive stakeholders sometimes use this strategy to block out senior management from making decisions. Note that senior managers usually cannot follow a purely technical discussion. This means that senior management cannot control the decision—they cannot control what they cannot understand. This specific project was particularly “lucky” because one of the managers had enough knowledge of software technology to see through the subversive strategy and save the project. But it was merely a lucky coincidence. Many projects lack such a member who has just the right combination of political instinct and software skills.

How would the post mortem report look if this project had failed? That depends on whether it is written by a software developer or by a manager.

An average software developer (without political instinct) might give the following feedback: “The clients and our superiors were constantly changing their opinions. It was simply impossible for us to find out what their expectation...