Hacker News Reader

Brooks' law is not actually a law of physics though.

There is a lot of wisdom to it. But there are good ways to add resources and bad ways. Perhaps a team isn't getting help from another group. Perhaps there are some tasks that others could offload in a way that doesn't distract the team on the critical path, etc.

It's a good adage but it doesn't mean that you can never take steps to accelerate project delivery.

> Perhaps a team isn't getting help from another group

Then the team should communicate that to the other team themselves.

> Perhaps there are some tasks that others could offload in a way that doesn't distract the team on the critical path

That should be the decision of the team. If they need to cut down in order to stay on the critical path, then they should do so.

You seem to have a rather negative view of managers.

In my experience, good managers can be quite valuable negotiating with other organizations in the company and with getting needed resources. In fact, I'd say that's a pretty significant part of their job.

Brooks law applies to a late project. However if the project isn't late yet - recognizing it will be and adding the right people now can make a difference in preventing it from becoming late. This is hard: first you need to add the architectures and senior engineers (both are badly needed on some other project that will be late without them) spending a few years getting the right frameworks in place, only then can a bunch of new teams join - you take a hit while they learn the new architecture and framework, but a few months latter they are all getting their part done in near isolation. (note isolation - this implies you have figured out the modules correctly to avoid communication problems - a hard problem in itself)

> So if the manager asks that for a late project, they are probably incompetent.

Not necessarily. I've seen/heard engineers who take great glee in pointing this out, but they don't understand the real dynamic. The managers have probably read the mythical man month too.

If as a manager you report a problem to your boss, you're likely to get "help", even if you already have a plan. Sometimes the least costly "help" is to accept additional "resources" and fence them off someplace they don't do damage so that the rest of your team can execute its real plan. Turning down help can damage your credibility/relationships which is what you depend on to be "allowed to be successful". It's emotions, not logic.

Or, if you really really want to, you can tell your boss they're an idiot and need to learn about Brook's law.

>The managers have probably read the mythical man month too.

Some sure, but not the one's violating all of its conclusions...

>Sometimes the least costly "help" is to accept additional "resources" and fence them off someplace they don't do damage so that the rest of your team can execute its real plan. Turning down help can damage your credibility/relationships which is what you depend on to be "allowed to be successful". It's emotions, not logic. Or, if you really really want to, you can tell your boss they're an idiot and need to learn about Brook's law.

Well, this doesn't contradict what I wrote above though. Just finds for a more polite way to handle the situation and not let the extra "help" make a mess of things! But it's not like I suggested telling anyone directly they're an idiot!

Brook's Law always reminds me of one of my favorite Dilbert cartoons:

https://dilbert.com/strip/1996-04-15

"Adding manpower to a late software project makes it later" is not hat I even want to argue about. Discovering that a project might run late, and then doing the right thing about that is.. but how is one doing "the right thing" if developers don't want to communicate estimates vs. reality?

"For a large one, 20% accuracy is science fiction stuff compared to the actual accuracy rates of big projects.." (exactly, I made that point as well) "..especially the kind with changing requirements, new issues discovered en route, etc (which is most of them)." If you are working in an environment where shipping something at some random point in the future is fine, well, good for you. The rest of us doesn't work in that world, which means that if you start a large project, lets say over the scale of 1 year, you cannot not talk about progress during that year. This is the point that I want to make.

In that sense: "5 hours spent on X" means, dishonesty aside, that 5 hours have been spent. This has some meaning, namely:

- a) if the estimate has been 1 hour, and this doesn't cancel out over time there is a systemic problem which puts the entire estimate to question. So someone should do something about that, and, whatever that something is - adding new or different resources, changing the goal, changing the timeline, whatever), it is usually not something that developers could do. (Not that I think 5 hours is a useful estimate size for any feature; 1 week, on the other hand, for a set of features would probably be useful)

- and b) if you figure out that team members are frequently spending more than 8 hours per day for whatever features (adjust 8 hours to whatever the team agrees upon) then the team is overloaded, the workload is not sustainable, and, again someone should do something about that...

Really, it shouldn't come as a surprise that - opposite to developers' lore - managers really do add value, especially when they are good managers.

What you get from Brooks Law is really that one should never put more people on a project? (Late or whatever?)

That's an insane idea (it does lead to the conclusion that the optimal team is zero sized), and not an answer to the GP's claim that a good manager must know when more people will/won't help.

The point of Brook's law isn't that extra people won't aid conclusion but that the overhead isn't free and unless the date is grossly overambitious (like 10% done) adding more people will add more tasks in "creating infastructure".

Lets take say Civilizations for example and say you need to build a spearman in 7 turns to not lose - but it would take 9 right now you already have production maximized without adding new buildings. Technically building a forge could speed it up to 6 turns but it takes 20 to build it. Even if it would help adding it right now would only make an intolerable delay even worse.

To get away from the geeky metaphor bottleneck and chokepoint management are a crucial part of making projects parallelizible across many developers and even then there are expenses to making them interoperate.

Unless you are grossly behind it is unlikely adding more people will help unless you are vastly overambitious and try to do something with one person that requires a team of thousands. In which case you have probably already failed too massively to help.

That's the pithy aphorism. Brook's actual claim is a lot more nuanced.

The output of n programmers working on a single task is O(n), but each one of those programmers must coordinate with O(n^2) colleagues. As more people are added, the coordination costs begin to to take over, and the project slips further and further behind. Thus, going from 2 to 4 programmers might be a great idea, while 20 to 40 or 200 to 400 may doom the project.

This is reason humans naturally form hierarchies. It changes the system from O(n^2) to like O(n log n).

Yup, and that was his solution. Small teams that don't need to coordinate much, and well-defined roles for the people on each team.

Nice observation :-)

It's potentially a bit better than O(n log n).

If a hierarchy settles into a strong tree structure, it approaches O(n) connections people have to handle - one bidirectional connection between each person and their immediate superior.

To put it a different way, a hierarchy has potential to scale without limit, or to put it differently again, the larger a system of people, the more they will be forced by necessity into a strict tree structure for the majority of 1:1 communications.

Except the people you need to interact with are very rarely the same people.

It's much more advantageous to form cliques. Small highly connected groups that work on the same thing, possibly with some lose connections to other cliques. That's the model that most closely resembles towns, cities, and even tribes.

Yes, but software project hardly ever tree-ize so neatly.

Talking to your team boss is good for high level guidance, but wont do anything when what you really need is the details on the workings of X a colleague knows.

I've always interpreted this "law" to mean just throwing resources at a problem without understanding the root cause will make things worse.

Like the idea of throwing good money after bad, if the problem isn't rooted in lack of resources (e.g., if the problem is actually rooted in bad communication, bad training, bad requirements, etc.) it's not going to help.

It's more that there is an amount of people that will minimize costs, any more or less than that and costs will increase, and another amount of people that will minimize time, again, any more or less and time increases; also, adding people in the middle of a project imposes a nearly proportional loss on time and costs.

He didn't even get deeply into differences between people in that chapter. It's just very basic stuff that is on project management 101 since forever. Yet he had to write it down, and most people still don't seem to understand it.

>I've always interpreted this "law" to mean just throwing resources at a problem without understanding the root cause will make things worse.

It's more about communication and coordination overhead as teams get larger (and new additions need to be brought up to speed etc).

>What you get from Brooks Law is really that one should never put more people on a project? (Late or whatever?)

Where did you got this idea from what I wrote (in fact, from my direct quote of Brooks' law)?

>That's an insane idea (it does lead to the conclusion that the optimal team is zero sized)

That adding people to a late project makes it later doesn't "lead to the conclusion" that "optimal team size is zero".

That's what's actually insane (one common form of insanity is following a logic to extremes without caring for nuance and limits).

Just that more people is more overhead (e.g. managerial and communication and agreement overhead), more people later equals more time to bring them up to speed and hand-hold them until they're ready plus the added overhead (related with more people) even when they're ready.

Brook's law doesn't say you should never put more people on a late project. It does say that you should not realistically expect the project to finish at (or sooner) than the initial estimate because of you adding more people.

In other words, for a late project with X persons working and M estimated months to completion. The real completion with X persons might be MR months, and with more persons X' it could get to MP. Adding extra programmers won't (per Brook's law and based on typical observations) ever help it reach M.

Sometimes adding more persons will make things worse, where MP > MR, other times they can help finish faster than the "actual" (not the initially estimated) finish date, so that MP < MR.

So it might still be advisable to add extra people -- it just wont (per Brooks law) get you to finish in M, and in some cases might even get you further from MR.