[dexen]

A great koan, thank you.

There's also a related, from-the-trenches, story:

It is a very humbling experience to make a multimillion-dollar mistake, but it is also very memorable. I vividly recall the night we decided how to organize the actual writing of external specifications for OS/360. The manager of architecture, the manager of control program implementation, and I were threshing out the plan, schedule, and division of responsibilities.

The architecture manager had 10 good men. He asserted that they could write the specifications and do it right. It would take ten months, three more than the schedule allowed.

The control program manager had 150 men. He asserted that they could prepare the specifications, with the architecture team coordinating; it would be well-done and practical, and he could do it on schedule. Futhermore, if the architecture team did it, his 150 men would sit twiddling their thumbs for ten months.

To this the architecture manager responded that if I gave the control program team the responsibility, the result would not in fact be on time, but would also be three months late, and of much lower quality. I did, and it was. He was right on both counts. Moreover, the lack of conceptual integrity made the system far more costly to build and change, and I would estimate that it added a year to debugging time.

-- Frederick Brooks Jr., "The Mythical Man Month"

[nine_k]

I heard someone once said: "I bought a copy of The Mythical Man-Month for my manager. Actually, two copies, because he always has so little time."

[fjsolwmv]

That sounds specious - grass is greener fallacy. The evidence was that the CP team failed at the job. But where is the evidence that the architecture team would succeed?

The general suspicion of TMMM is that it extrapolates from failure but assumes that some untried else would be better.

[coldtea]

>That sounds specious - grass is greener fallacy. The evidence was that the CP team failed at the job. But where is the evidence that the architecture team would succeed?

Anybody who has worked for a couple of decades of large software project, doesn't need any, cause they have seen this play out time and again. Brooks doubly so -- he literally wrote the book on software development timelines.

Sure, technically you're right.

But it's not like every piece knowledge needs to come packaged in a fancy LaTeX, with confidence intervals, and control groups. Sometimes experience alone is enough to assure us that the rain is wet and that a team of 150 will invariably fail in this way when assigned such a task compared to a team of 10.

[njarboe]

Seems like a good way to go would be 15 isolated teams of 10. Some teams might make the schedule. Pick the best project at that point. Big bonuses for the people that get it done and extra for the final winners. Seems like a huge waste of effort, but it looks like that is the way to go. This would be similar to what happens when a company just buys a small startup that has created what they need.

[loup-vaillant]

Fred Brooks probably had reasons to think the untried else would have been better. His experience, hindsight from later cases, and also the architecture manager's predictions, which did turn out correct.

When someone makes three predictions, two turn out to be correct, and the third ended up not tried, we would do well to think twice before dismissing that third prediction.

[stephengillie]

Why didn't he work internally to prevent these issues? It sounds like he was pleased to let them fail, so he could be correct with no effort.

Why are we taking advice from someone who lets others fail so he and his team look better? This kind of internal competition destroyed Motorola and damages many other organizations.

[loup-vaillant]

> Why didn't he work internally to prevent these issues?

What makes you think he didn't?

> Why are we taking advice from someone who lets others fail so he and his team look better?

From the quote, Fred brooks was clearly the boss of both the architecture manager and the control program manager. He wasn't part of any one team. I don't see the kind of conflict of interest you're hinting at.

> It sounds like he was pleased to let them fail, so he could be correct with no effort.

To me, it sounds like he simply made a bad call, and was saying "oops".

[stephengillie]

Let's make "better" the enemy of "good enough". Then we can blame anything on the CP team, making the architecture team look better without any effort or proof on their part.

Where is the koan where the Master tells the manager to hire better programmers? The Master doesn't because it's bad advice up chase waterfalls, unicorns, and 10x devs.

[rossdavidh]

I see what you're saying, but the alternative would be to say that you could never learn anything from real-life in-the-trenches experience, because business organizations rarely if ever do something two different ways.