Brooks' Law and related matters: why projects go awry and companies waste time

I was delighted to discover Brooks’ Law recently. Do you know it? I didn’t, though it’s far from new.

Fred Brooks first stated it in his 1975 book, The Mythical Man Month. It tells us that in a software project that’s running late, adding additional programmers will make it later still.

Fred Brooks: still laughing

Now Brooks admits that this is a terrible over-simplification, and I’m sure it is. However, it seems to me to contain a powerful kernel of truth, that doesn’t just apply to software. However, my experience has been in software, and there it resonates strongly with me.

The reason why adding programmers may well slow things down is:

Firstly, the additions to the team have to be brought up to speed. The approach the project has taken needs to be explained to them, along with what’s been achieved so far, which can only be done by existing team members. The result is that there is a ramp-up period during which the new staff are unproductive, and the productivity of the other staff is reduced while they carry out training.

Secondly, the more people there are in a team, the more complex communication becomes. Between two people, there is only one communication link; between four, there are six links; between eight, there are 28. Combinatorial explosion, that’s called, and it’s dramatic.

In my experience, the most common answer to the communication problem is to speak to the whole team, at the same time. That’s called a meeting.

Now meetings are one of the two most powerful methods at the disposal of company executives to give the appearance of working while not actually having to do anything constructive. This is particularly true since there’s a common illusion that to be really important, a meeting has to be really long. So discussions ramble, go over the same ground again, and often involve people who haven’t prepared for them scribbling on flip charts, an exercise designed not so much to explain anything, but to clarify their own thinking – though it generally only reveals their confusion.

The other way executives contrive to create the illusion of work is by driving. It’s exhausting to drive from London to Manchester, so it must be work, right? Well, no. Going by train gets you there at least as effectively, and allows you to be productive on the way. But if that’s not your aim, going by car’s the answer: it’s as boring as a meeting, but it’s just as effective a way of persuading others that you’re actually doing something.

The communication problem is made far worse if the extra resources added to a team are off-shore. There is a high likelihood that some of the problem will be simply linguistic – an English-speaking project, say, to which a large number of non-English speakers have just been added. Just to make things worse, the off-shore staff will probably claim, and may even be convinced themselves, that they master the language. In addition, communication within teams that span time zones can be made difficult by simple chronological problems.

Nor is communication helped by poor specifications. I’ve seen this problem fall into both of the opposite extremes: an executive who refused to specify what he wanted from a project, on the grounds that he didn’t feel that was his job (“I’ll resign rather than have to do that,” he assured me); equally, I’ve seen executives who insist on specifications that fit a particular template and are often so long that no one can bear to read them. Most commonly, though, they’re simply half-baked: I saw a report emerge from a development project with the words “Delete This” neatly included on it, because that was what had been written on the illustration supplied with the specification.

The other problem with off-shore resources is that they are used because they’re cheap. A girl I was at school with bought a great deal of diet chocolate. She then gorged herself on the stuff, because since the diet effect was obviously going to be all the greater, the more she ate. Throw in enough off-shore programmers, and you end up with costs which will be as impressive as if you’d managed a small number of on-shore ones – but that would have required more of a management effort (see above).

This all takes us rather beyond the scope of Brooks’ Law. Still, it’s all part of the grist to the great mill of lousy software development so many of us have come to know and love since the days Brooks wrote.

Well, come to know anyway.