Congratulations − I won the lottery and you're all screwed!

I have worked at several companies − both as a consultant and as a full time employee − where one key person had unshared knowledge about some critical aspect of the business. Meeting such people fills me with a feeling of foreboding. I wish I could tell the manager of such a person what I know to be true.

"You're one resignation away from temporary operational seizure."

It is surprising to me − although less so each time I find such a case − that more managers do not find this situation as worrisome as I do. It is not as if people haven't seen such operational seizure in reality before. It appears that the same kind of nonchalance that sanctions other reckless behavior propels managers to think "it will never happen to me; Joe will never quit on me like that".

And yet, it happens every day in organizations small and large across the land.

It could be that we deny the possibility of operational seizure because it is not a pleasant thought. We have to force ourselves to think about unsavory outcomes before we can think about solutions. Crossing that valley of doom before we may reach any safety is perhaps too depressing for many people. However, simple refusal to consider unsavory outcomes doesn't reduce the probability of those outcomes by one iota. Positive, can-do thinking is good until we have to think about risks.

Lister and DeMarco talk about risks at length in their book "Waltzing with Bears". The one example they give that has stuck with me is the kind of thinking most parents subconsciously do with regard to their children. We, as parents, fashion all sorts of negative scenarios in our heads − some of them quite fanciful and even whimsical − and then undertake plans to protect our children from the effects of such accidents. No one begrudges us such negative thinking; indeed watchful observers would think of us as neglectful parents if we were to ignore the dangers that could possibly befall our children. Yet we fail to take the same lessons when dealing with responsibilities at our workplace. We willfully neglect possible risks, including the risk of unexpected staff attrition, when planning projects or setting goals.

The core values of Extreme Programming; especially feedback and communication; are geared towards mitigating this risk. One of my professional goals is to help people realize the effectiveness of these values (and courage, simplicity, respect and others). I want to help create a culture where people are treasured because of the value they add by their presence, not the feared loss of value they would cause by their departure.

"Tropical Tricia's Paradise" - A variant of "Werewolf"

Tropical Tricia is a variant of the team game known as Mafia or Werewolf − adapted for the world of software development. This variant changes the metaphors from "village", "killing" and "lynching" to "team", "sending off to vacation" and "firing", respectively.

A stated goal of this variant of the game − and something that sets it apart from the other variants − is to make the lines between "good" and "bad" ambiguous. This is a reflection of the real world of software development where many decisions have both passionate proponents and opponents, making simple "good" and "bad" labels insufficient.

The following instructions are based on those found on the Portland Werewolf website (http://portlandwerewolf.com/rules).

The players represent a typical project team led by two or more project managers (Tropical Tricias) and containing several Tired Team Members. Since the team members are "tired", the Tropical Tricias want to send them to a Tropical Paradise for some much needed rest and relaxation. However, the team members − tired as they are − want to continue working and do not appreciate the concern to their well-being shown by the Tropical Tricias. To do this, they try to find the Tropical Tricias and have them relieved of their duties, or "fired". Other roles in the game try to discover the identity of the Tropical Tricias or zap the e-mails that Tropical Tricias send at night.

Setup

The players sit in a circle or around a table, where everyone can see each other.

You will need scraps of paper or cards containing the different roles. Each player takes a card and that will be their role for the game. It is vital for game play that no one knows what each other's role are, except for the moderator.

An example distribution of fifteen players is two Tropical Tricias, two Speedy Sys Admins, one Daring Director, and everyone else is a Tired Team Member.

One of the roles is a Moderator. If you are playing with a group of people that have not played before, it will be beneficial to pick a player that has played before to be the moderator, so that first time players can understand how the game is played.

Game Play

Night

The moderator says, "Night has fallen, the office is closed. Everyone go home and off to sleep." All the players close their eyes. The moderator then asks the different roles that perform tasks at night to wake up (open their eyes), find one another, perform their tasks and then go back to sleep (close their eyes).

Tasks consist of sending another player to the Tropical Paradise, "saving" another player from going to the Tropical Paradise, or gaining knowledge about another player. The tasks are performed by pointing to other players for the Moderator to see. The Moderator can then respond with a positive, thumbs up, or a negative, thumbs down, if the task was to gain knowledge. See the roles below for more details on their tasks.

In order to allow all players to interact the first day, you may choose to not have the "night" players perform their roles the first night, just find each other. For example, the Tropical Tricias will choose to send someone to the Tropical Paradise every night. If they do so the first night, then that player doesn't get a chance to play during that game.

Day

When the players that perform tasks at night have completed their tasks, day breaks. The moderator says, "The day has begun. We're already at work. Everyone wake up!" All the players open their eyes. If a player has been sent to the Tropical Paradise, the Moderator then says, "Player X has been happily sent to the Tropical Paradise." That player is now out of the game and is no longer allowed to say anything. As an added twist, it is recommended that the role of the player not be revealed until after the game ends.

It is now the remaining players' time to choose a player to fire. Players can say anything they want. Deceit, misdirection, and out right lying − aka "confidentiality", "discretion" and "adherence to corporate policy" − are encouraged, especially for the Tropical Tricias. Players discuss and try to build cases for who they think the Tropical Tricias are.

A player suggests that another player is a Tropical Tricia. The moderator then asks the other players if anyone seconds their suggestion. If there is a second, the accused then gets a chance to give their defense. Then the moderator asks for a vote, "Please raise your hand if you think player X is a Tropical Tricia and should be fired." If the majority of players raise their hand, the player is fired and is now out of the game. If there isn't a majority, then the players go back to discussing who to fire until the group comes to a consensus, they pick a fellow player to fire, and night falls again. As an added twist, it is recommended that the role of the fired player not be revealed until after the game ends.

Winning

This cycle continues, night into day, day into night, until either all the Tropical Tricias are fired or the number of remaining Tropical Tricias is more than or equal to the number of remaining Tired Team Members.

Roles

• Moderator − The moderator isn't actually a player but runs the game and keeps it moving.


• Tired Team Member − Team member responsible to delivering the project. They work during the day and sleep at night.


• Tropical Tricia − A typically overworked Project Manager. A Tropical Tricia works during the day and catches up on e-mails at night. Being a good Project Manager, she picks one player (of any other role) each night to send an e-mail to, informing that player that s/he has been sent to a Tropical Paradise for some much needed R&R. That player is no longer part of the team and is free from the stresses and challenges of delivering the project. Tropical Tricia is aware that her concerns for her team members is particularly irksome to the Daring Director (whoever he may be). She's also aware that the VP (if present) can have ambivalent feelings towards her.


• Daring Director − A Program Director who, while respecting people's right to R&R, is overly concerned about delivering the project. As such, s/he is not completely enthused by Tropical Tricia's approach to letting people go to the Tropical Paradise. The Director wants to fire Tropical Tricia so that the rest of the team can work on the project. Each night the Director points to one player. The moderator responds with a thumbs up if that player is a Tropical Tricia, or thumbs down if they are not.


• Speedy Sys Admin − The Speedy Sys Admins are sick of all the e-mail traffic created by Tropical Tricias. Unfortunately, because of privacy concerns, they cannot zap all the e-mails coming from the Tropical Tricias. They can only block e-mails directed to a particular player. Sys Admins choose one player whose e-mail will be monitored each night. If the player they chose gets an e-mail from Tropical Tricia that night, that e-mail is zapped and the player gets to stay on the team, working on the project.

Optional Roles

• Office Gossip − The Office Gossip is very jealous of Tropical Tricia and wants to stop her any way she can. She can open her eyes when the Tropical Tricias are awake and sending e-mails, so she can have the Tropical Tricia fired. However, if the Office Gossip is caught with her eyes open, she herself is immediately fired because of her unethical behavior. (Variation: if the Tropical Tricias discover the Office Gossip with her eyes open, they may signal to the Moderator to spare her life on the condition that she join the Tropical Tricias.)


• Agile Consultant − On the first night, the Agile Consultant points to two players. Those players are considered Pair Programmers. If one of them is sent to the Tropical Paradise or fired, the other one has to go as well.


• VP − Each night the VP points to one player. The moderator responds with a thumbs up if that player is a Daring Director, or thumbs down if they are not. The VP may choose this information to either back the Daring Director's attempts to fire the Tropical Tricias, or the VP may choose to fire the Daring Director himself and side with the Tropical Tricias. (Variation: The VP may open his eyes when the Tropical Tricias are awake and signal to them that he is siding with them with a "V" signal. Of course, he may be just "following company policy" when he says that ...!)

Net Nastiness and Road Rage

A couple of years ago, Martin Fowler wrote about Net Nastiness in his usual lucid style. His recommendations about "[making] our communities the kinds of places we want to be in" is true for all communities, perhaps especially so for online-only communities, which have no other means to rescue themselves once pervaded by Net Nastiness.

I believe there are some parallels between Net Nastiness and Road Rage.

1. Both happen when the offender feels physically secure from retaliation (the security of a vehicle, the security of anonymity on the Internet)

2. In both forms, the offender is unaware of the personhood of those he is offending. Often, their personhood is erased by using an impersonal epithet to refer to them ("the beige jalopy", "the @JavaNewbie")

3. In both forms, the interaction between the offender and those offended is fleeting, with a very low probability of any further interaction in life

After recently becoming the unwitting subject of a bout of NetNastiness on Twitter, I realized that for micro-blogging sites, these parallels hold even more strongly than for the more traditional blogs and wikis. In the noisy world of Twitter, spewing a short insult like "@ThatUser is a bumbling idiot!" is the online equivalent of cutting in front of someone, flipping them the bird and then taking the next exit on the highway.

While I'm not sure what's the right way to reduce Road Rage, as far as reducing Net Nastiness is concerned I believe following Martin's suggestions is valuable, nay, necessary. By speaking up, contacting administrators, flagging inappropriate posts (where the technology allows it) and switching away from chronically nasty communities; we can make the Internet a more enjoyable, informative and habitable place for the vast majority of us.

(Re)Thinking Functionally

Last Saturday, I attended the very vibrant and well-put-together Chicago Code Camp. A couple of the sessions I attended were by Dean Wampler. They were both about Functional Programming (in Ruby and Scala, respectively). 

To me, the most significant transition towards functional languages is the art of thinking functionally. Or, re-thinking functionally − since when I started programming, C was the rage and functions were all we had. Thinking back, we could have used function pointers as explicit implementations of closures (sort-of) rather than as a hack towards creating poor-man's-C-objects (= structs and its related functions in one C-file).

I suppose we were young then. Some of us, at least (the ones who were writing code in late 80s / early 90s, that is). We, who had grown from writing assembler code to the (slightly) more abstract syntax of C, followed the evolution of C-like languages.

It so happened that C (with functions and function pointers and structs) evolved towards C++ (with classes and objects) rather than towards a true FP language (with true closures − and perhaps a canonical implementation of lambda calculus).  

Which brings me back to my current challenge. After having spent the last 15+ years not only viewing the world around me in terms of classes and objects but also thinking that way, it takes some effort to (re)start thinking in terms of functions. 

Powerful analogies can help (or hinder) this transformation. For me, the turning point towards "thinking-in-objects" was when a college professor analogized the breaking of a glass when it hit the stone floor (but not when it hits a rubber mat) as the different interactions between the glass object, the floor object and the rubber mat objects:

shards = glass.strike(stone-floor);

glass  = glass.strike(rubber-mat);

I suppose I should restart thinking in terms of (pseudo) lambda function which transform the glass into either shards or the glass (= identity function) depending on the parameter:

F(m)(n) = shards, ∀ m ∈ {glasses}, n ∈ {stone-floors}

        = m,      ∀ m ∈ {glasses}, n ∈ {rubber=mats}

        = undefined, otherwise

I've been up this hill before, although it'll still take some effort to get to the summit again. I am happy and excited to be able to undertake the journey.