Dark Side of Software Engineering

Table of Contents

List of chapters:

Part 1:

• Subversion - focuses on people who wish the software project to fail; gives statistics on motivations for subversion, examples of situations, and suggestions for dealing with subversion.
• Lying - lying is a chilling but ubiquitous activity, with outcomes that range in seriousness; the chapter explores survey results on motivations for lying and various responses to deal with it.
• Hacking - covers examples of hacking, definitions, important concepts, intellectual property, hacker subculture, how hackers make money, social engineering; specific mention of Operation Aurora
• Theft of Information - ranges from subtle to blatant; often done to accomplish a specific goal; opens a much broader discussion of intellectual property.
• Espionage - not a common occurrence, even in banking/defense, at least on software projects; but included nonetheless.
• Disgruntled employees and sabotage - this topic focuses on the "who," not on the "what" - a disgruntled employee may utilize a number of methods, but the book spends a chapter discussing the particulars of disgruntled employees.
• Whistle-blowing - this is not an act of wrong-doing, but an act of exposing wrong-doing; but whistle-blowing is not always an inherently good activity; it can be misguided; leaks are sometimes driven by ulterior motives

Part 2: Opinions, predictions, and beliefs

• Automated crime
• Playing make-believe
• Dark, light, or another shade of grey?
• Rational software developers as pathological code hackers

Part 3: Personal anecdotes

• Officer and gentleman confronts dark side
• Less carrot and more stick
• Virtual software teams
• To lie on a software project
• Merciless control instrument
• Forest of Arden
• Hard-headed hardware hit-man
• A lighthearted anecdote

Part 1

Great quote: "Lying... an take many forms in the computing and software fields. One of those forms is simply claiming to have done something that you haven't, in fact, done. - p. 85"

Gotta have that hustle - and that ability to say, I probably need some help, or a reference, maybe from my own website.

Subversion

Some great motivating examples help explain exactly what problem the authors are discussing:

• Sprinter preparing to break the 100 meter record; subversion through distractions, subversion by ordinary person in the stands, subversion by another runner with expertise on when to subvert
• Faculty feedback system - anonymous feedback system on lectures, several interested parties (students, faculty, administrators), many conflicting points of view, who owns it, who uses it, what it will affect, how to authenticate without identifying, etc. Some teachers had hidden motives (impacting consulting business). They decide to subvert the feedback system.

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... 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...

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 contrl 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.

- p . 20

Cooperative effort:

• Another example - large corporation and small consulting company
• Large corporation starts large and significant project with small consulting firm, providing most of its revenue
• Project intentionally fails or damages project, both companies experience significant financial losses, large company sinks the small company financially
• Motivation: buy up the small company at a lower valuation, maybe even pick the project back up, and continue with corrected "mistakes"

Evil teammate:

• Use of bug-tracking system to subvert attack on project
• Mediocre developer gunning for job in upper management
• Forced all details of the process and project to go through the bug tracker
• Gained effective control over policy settings for developers and project leads
• Project manager and other colleagues did not see attack coming b/c took long time

Here is what they should have done: Recognize the methods employed by the subversive employee as those of a political attacker and respond accordingly. There is a large body of knowledge (which is hundreds of years old) about how to thwart the efforts of political tricksters. An effective defense would have first required learning some of it. The project lead, her peers, the management, and the other members of the technical staff were all ignorant of the patterns, ignorant of political attackers, or simply unaware of the attacks.

Here is what they did: the project lead had a nervous breakdown and hasn't recovered since; the manager quit in disgust and retired from the industry. The other project leads and members of the technical staff were mostly dumbfounded - they had never encountered this behavior before. The person who shared the anecdote reacted by learning about organizational psychology and political strategy.

- p. 23

Example of thwarting subversive efforts:

• Attempts by a union to subvert talks about new software
• Union reps demanded they had to get certain information to give their okay
• Was told, union reps would contact him. They didn't.
• He called, could not get ahold.
• Finally got in touch Friday afternoon at 4:30.
• Had spent the prior weeks gathering information anticipated, managed to obtain most of the information ahead of time
• Able to arrive on Monday with information requested, union reps had to give the okay.
• There was no way to tell that the union was being subversive; no one told him; but during user training sessions, felt strong resistance from union members, learned the topics they had concerns about, researched those topics specifically
• Subversive stakeholders are not subversive openly
• This must be used against them

Studies of project success/failure factors:

• Verner 2006
• Jeffrey 2006
• KPMG 2005
• Nelson 2005
• Ewusi-Mesah 2003
• Glass 1998
• Management problems cause failure more often than technical problems

Software project management best practices:

• Humphrey 1992
• Morasco 2005
• Glen 2003
• Miller 2004
• Boehm and Turner 2004
• Thomsett 2002

Stakeholder - a person inside or outside the project who has an interest in the project and influence over it

Subversive stakeholder - a person who wants the project to fail (to sabotage, disturb, or destroy a project; only those who act intentionally to detriment of project are considered "subversive"; incompetence or those unaware of consequences of actions are not considered subversive.)

Survey results:

• Over 50% said they had encountered subversive behavior
• Median of all responses: 20% of projects involve subversion
• Varied levels of frequency - some think subversive activities rare (<5% of projects), some felt were common (5-80%), and some felt it was very frequent (>80%)

What are motivations of subversive stakeholders? Grouped into 11 categories:

• Egotistic motivations conflicting with corporate goals
• Job security
• Revenge/disgruntled employees
• Challenge of authority/ego reasons
• Competition between individuals/rivalry
• Competition between departments/organizations
• Competition for budgets/resources
• Resistance to change
• Disagreement on major architectural/technological choice
• Disloyal partners
• Split in upper management

How was subversion discovered, if at all?

• Subversive activity carried out in the open (during meetings or in email)
• Informal network - cadre of people exchanging faulty information, groups intimidating others
• It is not a single event - it is a process; rarely a singe action that can be pointed to and labeled as subversive, but rather is often a pattern of behaviors over time
• Case-specific discoveries (false progress reports, withheld information, no progress reported)

How to defend against subversive stakeholders?

• Apply quality project management practices. This is an overly optimistic view, but is true - robust development process, project audits, use of checks and balances.
• Quality communication - open, honest, inclusive, focused communication via multiple media - reports, audit, and less formal involvement of all project players
• Psychology - improvement in hiring/firing process, focus on psychological and not just technical factors; identifying and keeping cooperative and capable people.
• Support from senior management to solve problems, when sufficiently severe.
• Tame the beast - asking subversives for their help, cooperation, convincing them.
• Fight the beast - if taming fails - eliminate them, work around them, fire them.

How do you identify subversion? Look for patterns.

• Rivals and enemies of project lead
  • Rivals within organization may be competing for positions in higher management (subversive insider)
  • May have personal conflict with project lead

• Subversive stakeholders within project:
  • Project lead acting intentionally to project's detriment
  • Subversive subordinate team members
  • Disloyal consultants (extending billing time)

• Customers and users
  • Users rejecting project, for various reasons
  • Dysfunctional person on customer side

• Subversive stakeholders outside of project
  • Those promoting other projects, fighting for budget allocations, those who would gain from the project's failure
  • Managers outside the project, not directly involved in project, launch missiles at project from a safe distance, do not "pay" in any way if project fails
  • Unfair partner companies - organizations with influence on project development; subversive behavior is a corporate decision

Conclusion:

• All too frequent activity
• Disparity in frequency of problems occurring
• Indications are, possibly 20% of software projects are affected by subversive activity
• 11 categories of subversion motivations listed
• There is a gray borderline between subversion and conflicting interests.

Lying

Motivating example: illustrates a situation in which multiple lies are told.

Management of software project with a problem.

• Lie 1: committed to schedule that was near impossible to achieve
• Lie 2: employees, afraid to say no to management, agreed to unreasonable plan/commitment.
• Lie 3: after a manager realizes a certain breakthrough approach could possibly result in project deadline being met, asks specialist to explore use of technology; specialist is convinced breakthrough cannot achieve this, but agrees to try.
• Lie 4: project lead continues to tell management that schedule will be met
• Lie 5: When scheduled date passes, making it obvious schedule is not being met, team expresses surprise
• Lie 6: team says it will try harder as project continues
• Lie 7: after project staggers to halt, project lead gives project manager phony reason for project inability to meet schedule
• Lie 9: communal lie, no one will admit to anyone else that the problem was the original, impossible schedule, and that they did the best they could. The same problem will occur on future projects.

Lying - intentionally distorting the truth.

There is reason to believe... that the number of incidents of lying is increasing. For example, in the popular psychology magazine Psychology Today, an article by Allison Kornet (1997) took the position that "the quintessential sin of the 1990s might just have been lying." (Kornet came to that conclusion after noting the "cliche" that "the 1980s was the decade of greed.")

Not much about lying in the scientific literature...

• Schein (204): "lying is not per se a moral issue" (moral relativist)
• Smith (2004): "deceit is normal, natural, and pervasive"
• Thomas Aquinas, Immanuel Kant - condemn lying in all of its forms

In the perhaps better-known NASA space shuttle Challenger disaster story, an article in IEEE Transactions on Professional Communication (1988) found what it called "miscommunication" as the key cause of the problem, resulting partly from this fact: "Thiokol engineers concluded that the O-Ring problems were serious before their management did. However, in their written communication, they varied the extent to which they voiced that seriousness, depending on whether the audience was internal or external."

- p. 83

One of the company principles in the (CONFIRM) case sent a letter to employees, saying among other things, "Our CONFIRM problem has many roots - one more serious than the other. Omse poeple did not disclose the true status of the project in a timely manner. This has created more difficult problems - of both business ethics and finance - than would have existed if those people had come forwards with accurate information."

(Note the polite euphemisms chosen to avoid using the confrontational term "lying" - even when people are visibly angry, they really work hard to avoid using the "L-word").

- p. 84

Lying... an take many forms in the computing and software fields. One of those forms is simply claiming to have done something that you haven't, in fact, done.

- p. 85

Survey of professional software folks about lying:

• 86% of respondents said they had encountered incidents of lying on software projects
• Most common three reasons were, lying about project cost and schedule estimation, lying about status reporting, and political maneuvering

Who lies (regarding estimation lying)?

• Mainly management or project leads, but also developers and marketing
• Many people know estimates are wrong (developers, project leads) without doing anything about it
• 42% of respondents said the motivation of the person doing the lying was to cave in to someone with more power

How to change the behavior:

• 21% suggested improved management techniques
• 18% suggested changing the "who" (who did the estimation)
• 15% were about improved estimation process

Status reports:

• 77% of respondents said had experienced lying in status reports
• Project lead is key player for status reporting
• Developers know more than the managers about who's telling lies

Motivations:

• incr. sales
• tell em what they wanna hear
• decr. workload
• lying has more advantages than telling truth