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

11–20 of 26 posts

Re: Coherence Penalty for Humans

#11

Post by fjsolwmv »

dexen wrote: post #4
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…

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.

Re: Coherence Penalty for Humans

#12

Post by bckmn »

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…

Years ago, an investor and I had about the same conversation. He was adamant about needing a spreadsheet that would allow him to model hires vs. cost vs. time.

I built a calculator that models that koan: https://www.andjosh.com/hard-numbers/

Re: Coherence Penalty for Humans

#13

Post by nine_k »

dexen wrote: post #4
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…

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…

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

Re: Coherence Penalty for Humans

#14

Post by kornakiewicz »

afwjaeif wrote: post #7
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…

Looks like this was taken from one of those super recompressed images from Indian programming groups on Facebook.

It's older than facebook, JPG and the idea of hiring programmers in India (1987).

http://www.mit.edu/~xela/tao.html

Re: Coherence Penalty for Humans

#15

Post by Tade0 »

wool_gather wrote: post #5
Tade0 wrote: post #3

Earlier quoted context omitted.

Recently I had a chance to quote this Koan explaining why I think a certain project went way over its original budget.

To management? I'd be very interested to hear how that went over.

Fortunately not exactly. It was such a massive project that everyone from my current team touched (or actually was touched by) it - including our current tech lead who had the misfortune of being assigned there briefly.

The topic came up on one of the introductory meetings and we shared our respective theories.

My take was that had this project had half the staff, it would take half the time to complete.

All and all there were over twenty people there doing daily standups.

Re: Coherence Penalty for Humans

#16

Post by loup-vaillant »

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.

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.

Re: Coherence Penalty for Humans

#17

Post by coldtea »

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.

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

Re: Coherence Penalty for Humans

#18

Post by thanatropism »

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…

But every fashionable dev methodology (agile, XP, yadda) becomes a fashionable PM methodology in 3 to 5 years.

Re: Coherence Penalty for Humans

#19

Post by njarboe »

coldtea wrote: post #17
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.

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

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.

Re: Coherence Penalty for Humans

#20

Post by watwut »

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…

Then again, the master programmer could have assign 5 people to this project and other 5 to different tasks (hello more detailed tests or research frameworks or even another team doing the same task independently) finishing the whole thing in one year with those 10 people.

So maybe it is more story about how we fail when we think about organization and negotiation. (The master programmer making sure estimate so easily suggest they won't be at time anyway).

Post reply on HN