Saturday, August 2, 2014

Privilege of different kinds

Privilege can come packaged in multiple forms. Here are a few I've experienced.

As a male software developer, I am given privilege that is undeserved. When I speak at conferences, or in front of a client, or while facilitating a workshop; I cannot help but be aware that if I were a woman, it wouldn't be as easy. For one, I would probably not have as many opportunities to speak in the first place. For another, I'd probably be taken less seriously when I did speak.

Being a man in my industry gives me undeserved privilege. And I despise that.

As a dark-skinned man with a security-alert-causing-name who was born in what, according to one news outlet, is the most dangerous country in the world, I lose privilege when I walk into an airport. It is depressing to know that in the US, even the law isn't necessarily on the side of justice and equality. It requires a much higher burden of proof to show discrimination in the civil, as opposed to statutory context. I have to accept the consequences that I am subject to a different set of laws and regulations when I'm in an airport.

Laws that suspect me because of my ethnicity, name and place-of-birth take away my privilege. And I despise that.

Then there's the privilege of working with people who I call my friends. The privilege of learning from them, being able to share with them what I've learned before. The privilege of their company, the insight into their thoughts and feelings, the human connection that is the underpinning of all creativity and an indispensable prerequisite to crafting beautiful software.

Working with creative, passionate, motivated, empathic friends is a privilege that I acknowledge consciously and for which I am very grateful. And I love that.

Wednesday, October 31, 2012

Beware of the translated Arabic Agile Manifesto

(And not just because the world gets its hackles raised when they see "Arab" and "Manifesto" in close proximity.)

The Agile Manifesto has been translated into many languages, including a few that are written from right to left like Arabic and Urdu. If you translate one of these using Google Translate [1], you'll be misled. Because Google will translate the last sentence starting with و یعنی (AR) or یہ اسلئے (UR) literally. Which comes out to "... we give greater value to items on the right side". This is a literal translation, but it's false. Because in the original Arabic, the "items on the right side" are الأفراد وتعاملهم فيما بينهم (individuals and their mutual interactions), البرمجيات الصالحة للاستعمال (correctly working software), etc. You know, the things we all value highly.

Context is everything. If you don't pay attention, your left hand won't know what the right hand values more.

[1] Very easy to do if you view the page using Google Chrome.

Saturday, February 25, 2012

Organizational Dysmorphia

In my consulting work, I've all too often observed organizations that have chosen to structure themselves in a way that is at odds with their stated goals and objectives. In extreme cases, the structure of such an organization actively subverts its raison d'être. I term such self-defeating structures as Organizational Dysmorphia.

A recurring example is when the development and quality-assurance teams are isolated from each other and evaluated on mutually inconsistent criteria. The development team is measured on the amount of functionality (feature-points, story-points, etc.) that they deliver to the QA team. The latter, in turn, are measured on the number of defects they can find in the software they receive from the development team. This arrangement actively dissolves any collective focus on quality and instead promotes a highly localized -- almost selfish -- way of thinking about one's job.

I observed another, more subtle example recently at a company. Some developers were responsible for creating interfaces. Others were responsible for implementing those interfaces. Apart from not promoting collective code ownership, this doesn't sound so bad at first. However, when you reprimand and reward (financially and otherwise) the different individuals based on exactly how the resulting software got broken, things quickly spiral down into a finger-pointing, responsibility-avoidance culture rather than one that values collective effort towards relentless quality improvement. This is what I found at that company.

Organizational Dysmorphia is consistent with and is a specialization of Conway's Law. Conway's Law is neutral: organizations are constrained to produce systems that mirror the communication structure of these organizations. Organizational Dysmorphia is the subcategory that deals with severely abnormal and dysfunctional instances of Conway's Law.

Monday, May 9, 2011

Magnanimous Writer

Martin Fowler's essay on TolerantReader was a timely read for me, since I've been dealing with both coupling with downstream services and providing services for upstream consumers at my most recent project.

It is nice to find on the other side of a TolerantReader a MagnanimousWriter. A writer that can anticipate and forgive some of the mistakes that readers that are less tolerant will inevitably commit.

One way we tried to make our writer tolerant on our project was to abide by the following contract to the upstream consumers of our RESTful services:

1. We will version our resources thus: /v/1/widgets etc.

2. We will not make any incompatible changes to any of our existing resources.

2.a. On a GET of an existing resource, we will never provide fewer entities than we do today, although we may optionally provide extra entities over time.
2.b. On a POST to an existing resource, we will never demand more required entities than we do today, although we may allow additional optional entities over time.

3. If we ever need to modify our resources in a way that we cannot live by rule #2 above, we will always create a new version of our resources: /v/2/widgets, etc.

One way we enforced this contract upon ourselves was through a test suite that validated our schemas. Here is a sample rspec test, (over)simplified:

describe "widgets view" do
it "should match the schema" do
orders = create_array_of_widgets_from_factory
assigns[:widgets] = widgets # sets "widgets" variable in the view
render "widgets/index.xml"
rng = File.join("/dir/to/relaxng/schemas/widgets.rng")
response.body.should be_valid_against_rng(rng)
end
end

The /dir/to/relaxng/schemas directory had its SVN commit access control set up in a way that only a few people (tech lead, etc.) could commit to it. This reduced the risk where a pair of devs (erroneously) changed the element "price" to "cost" in both the code and tests, committed everything, verified all builds were green ... and cause massive heartache with our upstream consumers when the app was put into production.

Of course, it is probably impossible for a writer to be magnanimous for ever. No team can support a very large number of versions of (even slightly) different versions of the same resource. On our team, we only had one version by the time I left but we seemed to be on the cusp of "v/2/something". However, it was our collective understanding that before we ever went to "v/3/anything", we would retire "v/1/everything".

Tuesday, November 10, 2009

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.

Monday, June 29, 2009

"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 ...!)

Thursday, June 4, 2009

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.