Prisoner’s Dilemma is one of the classical games in game theory. It’s an interesting abstraction of a whole class of situations, where two parties can choose between cooperative and non-cooperative behavior. It’s a kind of game where win-win and lose-lose result can be achieved. It doesn’t apply to situations like negotiating a price, where one party’s loss is another’s gain; prisoner’s dilemma applies to situation where two parties form a team and work together.

The key point of prisoner’s dilemma is that there are 4 levels of payoff, set up in such a way that the biggest gain is achieved by tricking the other party into cooperation and betraying it.

In the prisoner’s dilemma game, there are 4 possible game results.

In the generalized prisoner’s dilemma, strategies are called cooperate and defect.

I had an idea about extending prisoner’s dilemma to model bullying, and then try to find best strategies for such a situation. The main differences would include:

• There are many (not just two) players.
• Each player plays many times, with many other players, each game involves 2 players only.
• Players can observe games of other players, without taking part.
• The observation may be wrong, so it’s possible that defecting can be observed as cooperation.
• If a player defects and the other party cooperates, this information may leak into the environment. In such a case the defecting player can expect to be punished by all other players.

Bullying would happen when one player defects (attacks?), wins much and prevents this information from leaking into the environment. In the next game, its betrayed party, according to the “tit for tat” strategy, should retaliate. Unfortunately, if the it does so, the environment sees that as the first defection and will punish the previously betrayed player for retaliating, considering it an “attack”. This effectively prevents the betrayed player from retaliating and makes it vulnerable to the next defection. If the truth (i.e. which party has originally defected) never leaks to the environment, the bully can keep succeeding forever.

I’m not sure how to model the details, for instance, how does misinformation occur? In a deterministic or probabilistic way? Do players fully control the information that goes to the environment, or only partially?

A robust model should be simple, as much as possible, while still reflecting the key components of bullying such as environment and misinformation.

I managed somehow to survive 4 months with an enemy at the workplace. There are two more coming, so I need to stay alert.

When I started the new job, I thought that D. would become my best friend; that we’ll share interests and work closely together, designing and writing great software.

Unfortunately, D. has chosen to behave in a hostile way. At the beginning, I was looking for the cause within myself. Maybe I wasn’t nice enough to him? Or maybe I should admire him more? I worked harder and harder, doing my best to be nice and cooperative. Somehow, the harder I tried, the worse it had become. Everything I created or did, met one of the following responses from D.:

• “It’s unnecessary”
• “I hate it and I refuse to use it”
• Quickly writing the same thing, doubling my work
• The above, plus removing my code
• Veto

You probably think that it’s impossible. What does the boss say?

The boss hears all sorts of stories from D., mostly about why “it was necessary” to do what he did. The reasons were mostly proofs by assertion, statements firmly voiced, but without support. Boss was just taking D. on trust.

Another, humorous event was adding me to a Sourceforge project with a “support technician” role. What I do for the project, is software development, not carrying cables around.

Friends advised me to ditch this job. I have good reasons not to do that:

• I’m a contractor, I can’t break the contract without serious financial consequences.
• The subject (genetic data analysis) is very appealing to me, this is exactly the kind of work and/or research I want to do, this is where I want to develop.
• I like the boss, I believe that I can do more interesting projects with him (if he wants to).

Without much choice, I have developed techniques to survive. D.’s behavior did not change, but life is easier for me.

During the infamous meeting about interfaces in C++, the boss has asked me:

“Can you hide from D. your changes to the code?”

That’s asking one developer to hide from the other one. Well, that’s easy, it’s enough to stop contributing anything to the project. I mean, how can you possibly hide the changes when you work on the same thing?

What I do, is:

• I don’t talk to D., I don’t visit him at his desk, I don’t write e-mails and I don’t send him any IM messages. I only answer questions. Ah, one more thing. I submit bug reports.
• Instead of Subversion, I started using Bazaar. It’s a distributed source control tool, allowing me to manage the source independently, out of D.’s sight.
• I have separated the parts of the project that I’m responsible for. I keep them in a separate place, where D. cannot reach them. Even more, he even doesn’t know they exist. I have set up a separate Sourceforge project for a tool I’m writing. It’s a completely separate project with its own name, code repository and history. Write permissions are held only be me.
• I make sure that all the tasks that are assigned to me, are recorded in project’s issue tracking system. It has to be absolutely clear, what is the task and when it was assigned to me.

Hiding my work (and existence, for that matter) from D., has a negative side effect: I’m also hiding my work from my boss. I solved this by visiting the boss every morning, reporting all the things I’m doing and handing him results.

I don’t know if the boss is aware how wasteful D.’s behavior is. I bet it can be even reconciled into jingling coins, considering how much time I lost because I didn’t have information and documentation I needed, and how much time D. has spent removing my code and rewriting it.

Last Friday, boss has given me a new assignment. I asked him to record this assignment in our system. First, he told me that he usually doesn’t do that, because it’s quicker to do it verbally. Then he looked at me and asked why exactly I want him to record that assignment. I started to open my mouth, when he suddenly got it.

“No no, D. has now other things to do… well, okay, I’ll do that.”

I thanked him and left. I also made sure D. was notified.

I talked with my boss about problem with my co-worker. Although he says it’s not bullying, he sees that a problem exists. I can call that a progress.

I have ordered a book about bullying, as well as few other ones about C++ to have something to refer to when talking about technical things. Not to mention all the goodness of having them available every day.

The survival kit costs over £160 and consists of:

1. Bjarne Stroustrup: The C++ Programming Language
2. Gang of Four: Design Patterns
3. Bruce Eckel: Thinking in C++ (Vol 1 & 2)
4. Tim Field: Bully in sight

I’m working on a project written in C++, which, as many other projects, suffers from various bugs popping here and there. One of the best things to do in such situation, as recommended by Bruce Eckel, is to use unit testing to ensure that various pieces of software work properly.

I was utterly surprised to learn that the main programmer (D.) disapproved one of the changes needed by unit testing. Class interfaces, which in C++ are called pure abstract classes are well known and widely adapted. It’s mentioned in most C++ books, such as Bjarne Stroustrup’s C++ Language, Bruce Eckel’s Thinking in C++ and the Gang of Four’s Design Patterns.

It has became clear to me that the problem is not technical. It’s sociological.

Looking for help, I started reading teamwork-related pages on Wikipedia. My girlfriend asked what I was looking for and pointed me at the right term: bullying.

It’s the first time I had became a target of bullying. I only recently started to see the pattern in which D. acts. Until now, I was trying to find higher reasons for him to make my life difficult. I was sure that there was a reason, but I wouldn’t see it.

It’s a lots of small events which start to make sense altogether. For instance, my first two days at the new work, he was absent! There wasn’t really anybody who would get me started. The professor did his best, but he couldn’t really introduce the guts of the program to me. After that, it wasn’t any better, really. D. didn’t help me with anything. He wouldn’t care if I had all I needed to do my job. I did manage somehow, but it was nothing like proper task delegating. Being a new employee, I didn’t want to make too much noise. I just sat down and worked hard to get my job done.

If it was bullying I experienced first few days, is hard to tell. However, bullying is not a single event. It’s a series of events, where each event can be rationalized and explained. “I was absent because this and that.” or “I didn’t tell him that because I didn’t know that he didn’t know.” It’s the pattern that betrays bullying.

Bullying in school is often primitive. However, in a workplace, bullying can take subtle forms. In this case everything takes place in world of programming, technology and code. In this world, I’m one on one with the aggressor. Nobody around can really tell what’s going on. On the surface, people only see me sitting there in silence, working on my laptop.

Looking for more information, I found Bully on-line, which is a great source of information about bullying. I read lots of interesting things there, like: What makes one vulnerable to bullying? What’s typical bully like? What’s the typical motive?

From what I read there, the typical situation is when someone with a strong position but lacking competence is turning against someone competent, but with weaker position.

D., as far as I know, has no computer science education. I heard that he is a statistician, who learned C++ “on the way”. Perhaps D. has a problem with that and he wants to show the world that he can program better than a computer science MSc.

D. is deadly effective so far, destroying all my contribution to the project. He refused to use Autotools, he vetoed class interfaces (needed by unit testing), doubled my work in many places and generally refused cooperation (not explicitly, of course).

I’m going to talk to my boss about this on Monday. So far, he always avoids this topic. I try to tell him that the source of the problem might be not technological. Every time I try that, he says something like “let’s just, for now, do…” and some non-solution follows.

How it will end, is hard to tell. I will be working with D. for at least one and a half month more.