At a talk yesterday I asked an audience of program managers how many of them had read a vision document. Most of the 100+ in the room raised their hands. I then asked how many had read a document they thought was good: about a dozen kept their hands up.

I’ve asked this question dozens of times and it’s rare to find people who’ve read one they thought was good. Most teams (or start-ups) have some kind of written charter, even if it’s just a beat up e-mail, for what the over-arching goals are supposed to be.

Why are they often so bad?

I have 3 theories:

• They’re often written by committees. Five people get in a room and yield to mediocrity. Unless one talented person asserts him/herself as the lead author (e.g. Thomas Jefferson) the result is jargon happy, wishy washy, impenetrable tripe. You want a clear narrative, not a labyrinthine wishing well.
• They’re not written to serve the reader. What purpose do these things serve? If the people writing it don’t know, odds are slim what the write will be of use to the people asked to read it. If the goal is to catalyze, motivate or clarfy, it should be easy for any vision author to check with readers to see if it’s working. But if they don’t ask, readers might be afraid to tell.
• Author confuses hype with reality. A good vision document connects the future with the present, and gives tools to people to make faster decisions. All the hype and conjecture has a place, but it’s probably in the supporting materials, not in the directives or goals people are being asked to follow.

So why do you think vision documents and their ilk are often so painful reads? Politics? Cowardice? Lack of imagination? Labotomy? what?

In Fred Brooks’ Mythical Man Month, he states:

Brooks Law: adding manpower to a late software project makes it later.

In the book he notes that it is an “outrageous oversimplification”, but most laws of this kind are. The trouble is that people often use laws like this in a lazy fashion to end debate, assuming it is as universally applicable as an actual law of basic physics. It doesn’t take much effort to see that there are important exceptions. I hinted at them in chapter 2 of Making Things Happen, but here’s a full explanation of the notable caveats I’ve seen.

• It depends who the manpower is. Brook’s law assumes that all added manpower is equal, which is not true. Given the choice of adding a good programmer, who knows the code base and is friends with half the team, I’d consider it. Knowledge of the code and good relationships with the team offsets the two key reasons for Brooks law (ramp up and communication overhead). And if that individual has prior experience coming in late to a project, all the better. Some people are capable of playing the SWAT team / Ninja role, and that skill is orthogonal to programming talent: some are simply better are getting complex work done on unfamiliar terrain with a minimum of disruption.
• Some teams can absorb more change than others. Some teams are more resilient to change. They can absorb communication overhead and teaching duties better than others can. It’s well known that there is a wide range among programmers in their speed, but it’s also true there is a wide range of communication and teaching skills. Even if all teams pay a price for adding people, that price will vary widely and is not a fixed cost based on the # of people alone(e.g. n*n).
• There are worse things than being later. The conclusion most people reach is that, given Brooks law, you should never add people. But it doesn’t say that: it just says you’ll be later. That can be OK if you also get higher quality (not a guarantee of course). Time is not the only success criteria. If the person you’re adding fills an important hole in in the team, being later might be worth it.
• There are different ways to add manpower. The sad but popular approach is to throw people in without much explanation and let everyone figure it out for themselves. But if the manager clarifies why Sally and Rupert are joining, and defines good roles for them, with input from the team, they’ll be set up to make a smooth transition. This can also include assigning them a mentor who is capable and motivated to be their primary point of contact for on boarding issues. The more experience everyone has with mid-stream personnel changes, the better. Some tasks will always be better suited to assigning new people and it’s the manager’s task to figure out which ones those are.
• It depends on why the project was late to begin with. If the project was late because of inexperience or poor team practices, adding a small number of experienced people with those missing skills, and directing others to follow them, can eliminate some of those inefficiencies: not all knowledge or skill transfer requires long lead times. Therefore the added value of certain manpower is not just 1 additional programmer unit, but 1+, as they have a positive effect on the productivity of others. But more importantly, there are many reasons for being late that have nothing to do with the programming team personnel: no amount of programming staff modifications will resolve the psychiatric needs of team leaders or the dysfunctions of executives.
• Adding people can be combined with other management action. Contrary to popular belief, management is not a turn based strategy game. You can do more than one thing at the same time. For example, you can remove someone at the same time you’re adding manpower. This does increase volatility, but if you’re removing your worst, and most disruptive, programmer and adding one of your best, it can be a reasonable choice. Managers also have the option to cut or reorganize work across the project, improve tools and equipment, throw a social event to accelerate team relationships, etc. There are always ways for managers to provide cover fire. These all have disruption costs, but depending on the length of the project they might be offset.

Disclaimer: I’m sure there are specific cases where these exceptions do not apply. I am not suggesting the abandonment of Brook’s law, only thoughtful consideration for how it is applied. All additional examinations or applications of Brook’s law, or these exceptions, are welcome.

See also:

• A thoughtful critique of this post
• the social contexts of open source software, from the Cathedral and the Bazaar.