News for hackers. Stuff that matters.
Re:Books I recommend to my software engineering students by bcrosby95 on Thursday April 23, 2020 @09:28PM (#22963689)
From what I recall, it talks about 3 somewhat related things.

First is that adding people slows things down in the short term.

The second is that due to overhead, adding people won't give linear speed up in completion time.

And third, adding people won't help a project that is linear in nature. The common example is using 9 women to get a baby in 1 month.

Re:Books I recommend to my software engineering students by downerending on Thursday April 23, 2020 @10:42PM (#22964106)
That's a good summary.

My years suggest that he wasn't nearly pessimistic enough.

Re:Books I recommend to my software engineering students by ggm on Friday April 24, 2020 @12:24AM (#22964611)
You mean if you add 9 women you get a baby in 81 months?
Re:Books I recommend to my software engineering students by downerending on Friday April 24, 2020 @01:06AM (#22964827)
I mean that in the limit, adding the n+c'th person isn't just useless, it's devastating. If the optimal (in terms of calendar date of completion) size for a project is (say) three people, it is entirely possible, if not almost certain, that putting 30 people on the project will push the expected completion date to infinity. In other words, the project will fail.

Now, you might say, "I will just bench those other 27 people" and have them play cards or something. In most organizations, though, you cannot do this. Instead, they must be seen to be useful somehow. And if you have 30 people with their hands in a three-person project, no matter how peripherally, failure is all but guaranteed.

I have seen this many times.

Re:Books I recommend to my software engineering students by thr0w__4w4y on Friday April 24, 2020 @03:35PM (#22972053)
100% feel you.

Last time I worked at a big company, there was lots of dead wood, but one guy in particular was just a massive liability. Nice guy, tried hard, but utterly incompetent, and (I think there is a term for this?) he was unaware / ignorant of how incompetent he was. He would often check in code that would break the build (team of 300 engineers, large telecom system), he would write and run scripts that would bring computing clusters to their knees (this was late 90s, there are probably ways to mitigate that now), he would consume lots of high-quality talent's time with basic questions, etc.

I literally asked my manager if we could pay Leo to sit home and play video games. OF course, as you said, everyone's gotta look busy.

Here's the punchline: I learned a new term (to me, at the time... not sure I've heard it again) from a greybeard/wizard there -- this guy was a genius. He had a very appropriate term for Leo: negative producer.

Bingo!