Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Coherence Penalty for Humans

michaelnygard.com

Post reply on HN
Print view View original

21–26 of 26 posts

Re: Coherence Penalty for Humans

#21

Post by rossdavidh »

fjsolwmv wrote: post #11
dexen wrote: post #4

Earlier quoted context omitted.

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 divis…

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.

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.

Re: Coherence Penalty for Humans

#22

Post by rossdavidh »

js8 wrote: post #6

I like the article. I think, in general, (project) management could learn a lot from computer science. People working on operating systems etc. figured out solutions to a lot of problems like scheduling and so on. Another similar penalty with humans that is often ignored is caching of skills into working memory. For example, consider a process, like writing an expense, that is really simple. Because it's simple, it m…

I was in an organization where they decided to cut the "indirect labor" cost, which for some reason included secretaries but not engineers. So, fewer secretaries means more of the tasks they used to do for engineers, the engineers now had to do themselves. So, instead of one secretary doing travel expense reports for a couple dozen engineers, and doing them efficiently and well, you had a couple dozen engineers who don't do it often enough to know how, doing it badly and over a much longer (and more highly compensated) time. Multiply this by many different kinds of administrative tasks.

Re: Coherence Penalty for Humans

#23

Post by stephengillie »

kornakiewicz wrote: post #2

A manager went to the Master Programmer and showed him the requirements document for a new application. The manager asked the Master: "How long will it take to design this system if I assign five programmers to it?" "It will take one year," said the Master promptly. "But we need this system immediately or even sooner! How long will it take if I assign ten programmers to it?" The Master Programmer frowned. "In that ca…

The Master persists in smug obtuseness while forcing the manager to play games - which usually leads to an unemployed Master.

Re: Coherence Penalty for Humans

#24

Post by stephengillie »

fjsolwmv wrote: post #11
dexen wrote: post #4

Earlier quoted context omitted.

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 divis…

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.

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.

Re: Coherence Penalty for Humans

#25

Post by stephengillie »

loup-vaillant wrote: post #16
fjsolwmv wrote: post #11

Earlier quoted context omitted.

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.

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.

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.

Re: Coherence Penalty for Humans

#26

Post by loup-vaillant »

stephengillie wrote: post #25
loup-vaillant wrote: post #16

Earlier quoted context omitted.

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.

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.

> 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".

Post reply on HN