Are You Creating Micromanagement Zombies?

Do you manage other programmers, in any capacity? Then take Kathy Sierra's quiz:

1. Do you pride yourself on being "on top of" the projects or your direct reports? Do you have a solid grasp of the details of every project?
   
   
2. Do you believe that you could perform most of the tasks of your direct reports, and potentially do a better job?
   
   
3. Do you pride yourself on frequent communication with your employees? Does that communication include asking them for detailed status reports and updates?
   
   
4. Do you believe that being a manager means that you have more knowledge and skills than your employees, and thus are better equipped to make decisions?
   
   
5. Do you believe that you care about things (quality, deadlines, etc.) more than your employees?

A "yes" to any of these -- even a half-hearted "maybe" -- means you might be creating Micromanagement Zombies.

That's right, Zombies. Mindless automatons who can barely do anything except exactly what they are ordered to do, and even then, only when someone is strictly monitoring what they're doing and how they're doing it. Micromanaging the people you work with is arguably the exact opposite of what a competent team leader or manager should be spending their time doing. So if you're micromanaging at all, even the teeny tiniest little bit, step back and take a long, hard look. It's a sign of deeper problems.

Beyond that, who the heck wants to work with zombies anyway? Shouldn't you endeavor to work with the type of people who are good enough at their jobs that they can make sensible decisions about what they're doing? And they're not constantly trying to eat your brain? Well, figuratively speaking.

Building teams is like building software. It's easier to describe what not to do than it is to identify the intangibles that make good software development teams jell. But it's pretty clear that micromanagement is one of the biggest risks. In Peopleware, DeMarco and Lister establish seven anti-patterns they dubbed Teamicide:

1. Defensive Management
2. Bureaucracy
3. Physical Separation
4. Fragmentation of People's Time
5. Quality Reduction of the Product
6. Phony Deadlines
7. Clique Control

Wondering what number one encompasses? You guessed it: micromanagement.

If you're the manager, of course you're going to feel that your judgment is better than that of people under you. You have more experience and perhaps a higher standard of excellence than they have; that's how you got to be the manager. At any point in the project where you don't interpose your own judgment, your people are more likely to make a mistake. So what? Let them make some mistakes. That doesn't mean you can't override a decision (very occasionally) or give specific direction to the project. But if the staff comes to believe it's not allowed to make any errors of its own, the message that you don't trust them comes through loud and clear. There is no message you can send that will better inhibit team formation.

Most managers give themselves excellent grades on knowing when to trust their people and when not to. But in our experience, too many managers err on the side of mistrust. They follow the basic premise that their people may operate completely autonomously, as long as they operate correctly. This amounts to no autonomy at all. The only freedom that has any meaning is the freedom to proceed differently from the way your manager would have proceeded. This is true in a broader sense, too: The right to be right (in your manager's eyes or in your government's eyes) is irrelevant; it's only the right to be wrong that makes you free.

The most obvious defensive management ploys are prescriptive Methodologies ("My people are too dumb to build systems without them") and technical interference by the manager. Both are doomed to fail in the long run. In addition, they make for efficient teamicide. People who feel untrusted have little inclination to bond together into a cooperative team.

In the end, isn't trust what this is about? If you don't trust the people you work with -- and most importantly, actively demonstrate that trust through your actions -- should you really be working with them at all?

Finishing The Game

In yesterday's post, I asked this question:

Let's say, hypothetically speaking, you met someone who told you they had two children, and one of them is a girl. What are the odds that person has a boy and a girl?

Most people answer 50%.

Unfortunately, this isn't correct.

This problem, although seemingly simple, is hard to understand. For cognitive reasons that are not fully understood, while our intuitions regarding a priori possibilities are fairly good, we are easily misled when we try to use probability to quantify our knowledge. This is a fancypants way of saying there were almost a thousand comments on that post, with not a lot of agreement to be found.

The key thing to bear in mind here is that we have been given additional information. If we don't use that information, we arrive at 50% -- the odds of a girl or boy being born to any given pregnant woman. That's true insofar as it goes, but it's the answer to a different, much simpler question, and certainly not the answer to the question we asked.

Our question contains additional information:

1. The person has two children.
2. One of those children is a girl.

We can use that information to come up with a better, more correct answer. We know this person has two children. What are all possible combinations of two children?

BB, GB, BG, GG

We know that one of the children is a girl. This rules out one of those possible combinations of two children (BB), so we're left with:

GB, BG, GG

Of the remaining three possibilities, two include boys.

GB, BG

Thus, the odds of this person having a boy and a girl is 2/3 or 66%.

I noticed a few comments where people complained that the GB and BG possibilities are the same thing, and should have been reduced to

BG/GB, GG

Which equates to 1/2 or 50%.

If you made this mistake, you're in good company: so did Blaise Pascal, as the book The Unfinished Game: Pascal, Fermat, and the Seventeenth-Century Letter that Made the World Modern explains.

Here's how Keith Devlin describes the famous letter:

In 1654, the gambler Antoine Gombaud, whose noble title was the Chevalier de Mere, apporached his friend Pascal with some questions about games of chance, including the problem of the unfinished game. After some thought, Pascal found a possible solution but was not completely sure his reasoning was correct. Accordingly, he sent his ideas to Fermat to see if his countryman agreed with the argument. The brief exchange of letters that ensued -- and one letter in particular -- represented one of the most profound advancements in the history of mathematical thought.

I'll tell you one thing I learned from this book: It's amazing how many early advancements in math were based on gambling. I guess it's sort of the same historical relationship between video technology and pornography. Not that there's anything wrong with that. Anyway, the "unfinished game" I alluded to in my previous post title is the central topic of these letters between Blaise Pascal and Pierre Fermat. Here's a modernized, slightly simplified version of it:

Two players, Harry and Ted, place equal bets on who will win the best of 5 coin tosses. In each round, Harry always chooses heads (H), and Ted always chooses tails (T). Suppose they are forced to abandon the game after 3 coin tosses, with Harry ahead 2 to 1. What is the fairest way to divide the pot?

Let's enumerate all possible outcomes from the 2 remaining coin tosses.

HH HT TH TT

Only 1 of these 4 possibilities allows Ted to win. Thus, if the game has to be abandoned, the pot should be split 3/4 to Harry and 1/4 to Ted.

But, since Harry is already ahead 2 to 1, you might argue that it's nonsensical to consider all those "extra" possibilities; as soon as Harry gets that third head on a coin toss, the game is over. Thus, we only need to consider possibilities where the game would actually continue:

H TH TT

By this accounting, Harry would get 2/3 of the pot, and Ted 1/3. We know this is wrong. By leaving the game "unfinished" and not enumerating every possibility -- we've made a mistake. But how?

You don't need to be a mathematician to prove this. I'm just a crappy programmer, and even my crappy code can brute force the answer by simulating results from thousands of games.

var rand = new Random();
var results = new Dictionary<string, int>();
int tosses = 2;

for (int i = 0; i < 10000; i++)
{
    string result = "HHT";
    for (int toss = 0; toss < tosses; toss++)
    {
        result += (rand.Next(2) == 0) ? "H" : "T";
        if (Regex.Matches(result, "H").Count == 3 || Regex.Matches(result, "T").Count == 3) break;
    }
    
    if (results.ContainsKey(result))
        results[result]++;
    else
        results.Add(result, 1);
}

foreach (var item in results)
{
    Console.WriteLine(item.Key + " : " + item.Value);                
}

The unfinished games are not equally likely! But the results are definitely clear, and agree with what the equally likely finished games predicted: 75% for Harry, and 25% for Ted.

I've made awfully similar "unfinished game" mistakes before, in particular when writing a card shuffling algorithm. It was my hope in presenting this problem that you'll be able to recognize it too the next time you see it, even if the math behind it is not at all intuitive.

The Problem of the Unfinished Game

Today's post is a simple question.

Let's say, hypothetically speaking, you met someone who told you they had two children, and one of them is a girl. What are the odds that person has a boy and a girl?

Consider your answer carefully, without doing a web search, or reading the comments to this post. Don't cheat -- but be prepared to explain your reasoning, because the solution might surprise you.

It's almost like some kind of conspiracy or something.

Programming: Love It or Leave It

In a recent Joel on Software forum post Thinking of Leaving the Industry, one programmer wonders if software development is the right career choice in the face of broad economic uncertainty:

After reading the disgruntled posts here from long time programmers and hearing so much about ageism and outsourcing, I'm thinking of leaving the industry. What is a good industry to get into where your programming skills would put you at an advantage?

Joel Spolsky responded:

Although the tech industry is not immune, programming jobs are not really being impacted. Yes, there are fewer openings, but there are still openings (see my job board for evidence). I still haven't met a great programmer who doesn't have a job. I still can't fill all the openings at my company.

Our pay is great. There's no other career except Wall Street that regularly pays kids $75,000 right out of school, and where so many people make six figures salaries for long careers with just a bachelors degree. There's no other career where you come to work every day and get to invent, design, and engineer the way the future will work.

Despite the occasional idiot bosses and workplaces that forbid you from putting up Dilbert cartoons on your cubicle walls, there's no other industry where workers are treated so well. Jesus you're spoiled, people. Do you know how many people in America go to jobs where you need permission to go to the bathroom?

Stop the whining, already. Programming is a fantastic career. Most programmers would love to do it even if they didn't get paid. How many people get to do what they love and get paid for it? 2%? 5%?

I tend to agree with Joel's brand of tough love. What he seems to be saying -- after taking my usual poetic license -- is this:

Programming: love it or leave it.

Unless you're fortunate enough to work for a top tier software development company, like Google, Microsoft, or Apple, you've probably experienced first hand the huge skill disparities in your fellow programmers. I'm betting you've also wondered more than once why some of your coworkers can't, well, program. Even if that's what their job description says.

Over the last twenty years, I've worked with far too many programmers who honestly had no business being paid to be a programmer. Now, I'm not talking about your average programmer here. We're all human, and we all make mistakes. I'm talking about the Daily WTF crew. People that actively give programming a bad name, and you, as their coworker, a constant headache.

Like Joel, I'm not ready to call the current conditions a new dot com bubble yet, because business is still quite good. But one of the (very) few bright spots of the previous bubble was that it weeded out all the people who didn't truly love software development. Once the incentive to become an overnight dot-com genius programmer millionaire was gone, computer science enrollment suddenly dropped precipitously at colleges across the country. The only people left applying for programming jobs were the true freaks and geeks who, y'know, loved this stuff. The kind of people I had originally enjoyed working with so much. At least until a bunch of careerist gold diggers suddenly showed up and started polluting our workplace.

As much as the dot com bubble sucked, I was intensely glad to see these people go. Now I'm wondering if the current economic conditions are an opportunity to clean house again.

I mean this in the nicest possible way, but not everyone should be a programmer. How often have you wished that a certain coworker of yours would suddenly have an epiphany one day and decide that this whole software engineering thing just isn't working out for them? How do you tell someone that the quality of their work is terrible and they'll never be good at their job -- so much so that they should literally quit and pursue a new career? I've wanted to many times, but I never had the guts.

Joel implied that good programmers love programming so much they'd do it for no pay at all. I won't go quite that far, but I will note that the best programmers I've known have all had a lifelong passion for what they do. There's no way a minor economic blip would ever convince them they should do anything else. No way. No how.

So if a programmer ever hints, even in passing, that they might possibly want to exit the field -- they probably should. I'm not saying you should be a jerk about it, obviously. But if someone has any doubt at all about programming as a career choice, they should be encouraged to explore alternatives -- and make room for another programmer who unashamedly loves to code.

Then again, maybe I'm not the best person to ask. I spent Christmas Eve setting up servers. I'm on holiday right now, sitting in a hotel room in Santa Barbara, and you know what I spent the last two nights doing until the wee hours of the morning? Writing code to improve Stack Overflow. Oh yeah, and this blog post.

So I might be a little biased.

My Software Is Being Pirated

If you're at all familiar with computer history, you might have heard of Bill Gates' famous 1976 letter to the Homebrew Computer Club. The letter was written to address rampant piracy of Bill's earliest product, Altair BASIC, which was being passed around quite freely by hobbyists in paper tape form, without any sort of payment to Microsoft (or, as it was then called, Micro-Soft).

Bill was understandably upset about this state of affairs.

It's an interesting figure: less than 10% of the "users" had actually purchased a copy; the other 90% had pirated it. Let's compare that statistic with a blog comment left November 12th by one of the authors of the critically acclaimed indie game World of Goo:

last we checked the piracy rate was about 90%.

32 years later, and we've ended up back exactly where we started. That's not exactly a resounding affirmation of the human spirit, or anything.

That 90% piracy figure was later substantiated in a blog post:

First, and most importantly, how we came up with this number: the game allows players to have their high scores reported to our server (it's an optional checkbox). We record each score and the IP from which it came. We divided the total number of sales we had from all sources by the total number of unique IPs in our database, and came up with about 0.1. That's how we came up with 90%.

It's just an estimate though... there are factors that we couldn't account for that would make the actual piracy rate lower than our estimate:

• some people install the game on more than one machine
• most people have dynamic IP addresses that change from time to time

There are also factors that would make the actual piracy rate higher than our estimate:

• more than one installation behind the same router/firewall (would be common in an office environment)
• not everyone opts to have their scores submitted

For simplicity's sake, we just assumed those would balance out. So take the 90% as a rough estimate.

What makes this particularly depressing is that that World of Goo is not a game that deserves to be pirated. Not just because it's easily one of the best games of 2008 (and it really is -- please try the demo for Windows or Mac).

The crushing piracy rate is especially painful in this case because World of Goo was handcrafted by a tiny 2 man independent programming shop. Even a cursory 10 minute session is more than enough to demonstrate that this is a game built with love, not another commercial product extruded from the bowels of some faceless Activision-EA corporate game franchise sweatshop. Nor is this an exorbitantly priced bit of Adobe software that costs hundreds or thousands of dollars; it's a measly twenty bucks! Fifteen, if you count the fact that it's on sale right now via Steam. Oh, and did I mention that the developers explicitly chose to avoid any form of onerous copy protection?

Doesn't matter. 90% piracy rate. Just like Altair BASIC. And every other game.

Now, I'm no saint. I essentially grew up as a hardcore Apple // scene pirate, resolutely avoiding those public service announcements not to copy that floppy. I have a deep and personal understanding of the fact that not every person who pirates the software would ultimately buy it anyway. I was just a kid; I barely had money enough to have a computer at all. This is why the BSA's hypothetical piracy loss claims are more fantasy than anything else. Piracy is a natural state of affairs for users with lots of time and no money.

But it doesn't stay that way. Now that I'm older, I have money -- and a taste for software. I buy software all the time. I urge other people to buy software all the time. I've worked for companies that buy hundreds of thousands of dollars worth of software. I've even gone so far as proposing a Support Your Favorite Small Software Vendor Day, and I still try to live up to that goal. I have a budget set aside to buy some bit of software from a small development shop, each and every month. As programmers, we of all people should appreciate the message Bill Gates outlined in his original 1976 letter better than anyone else: buying software supports programmers.

But let me be absolutely crystal clear about one thing: as a programmer, if you write software and charge money for it, your software will be pirated. Guaranteed. Consider this recent example from the Joel on Software forums:

My software is being pirated.

I have contacted with the forum where is the post with the crack and with the business that he requested (I called him) this crack. But they do not seem to want to collaborate. What I do?

How I can prevent future actions like this?

Now, the users can download a demo limited by days from my website and others' websites. I'm using Quick License Manager....

Short of ..

1. selling custom hardware that is required to run your software, like the Playstation 3 or Wii
2. writing a completely server-side application like World of Warcraft or Mint

.. you have no recourse. Software piracy is a fact of life, and there's very little you can do about it. The more DRM and anti-piracy devices you pile on, the more likely you are to harm and alienate your paying customers. Use a common third party protection system and it'll probably be cracked along with all the other customers of that system. Nobody wants to leave the front door to their house open, of course, but you should err on the side of simple protection whenever possible. Bear in mind that a certain percentage of the audience simply can't be reached; they'll never pay for your software at any price. Don't penalize the honest people to punish the incorrigible. As my friend Nathan Bowers so aptly noted:

Every time DRM prevents legitimate playback, a pirate gets his wings.

In fact, the most effective anti-piracy software development strategy is the simplest one of all:

1. Have a great freaking product.
2. Charge a fair price for it.

(Or, more radically, choose an open source business model where piracy is no longer a problem but a benefit -- the world's most efficient and viral software distribution network. But that's a topic for a very different blog post.)

Now, it's up to you to prove me right and revive my waning belief in the essential goodness of the human spirit by buying a copy of World of Goo, ideally directly from the developers.

Or you could, y'know, pirate it like everyone else.