4 ms·
You should really read the book listed. It only saves time when work on a project is parallelizable, and only if the communication needs between folks is low. I
by ryan_lane 3y ago
You should really read the book listed. It only saves time when work on a project is parallelizable, and only if the communication needs between folks is low. It's not a matter of folks fighting, it's a matter of the amount of context needed to coordinate work. Often more people on a project results in the project moving slower, not faster.
- kragen 3y agodon't be an idiot, obviously i've read the book
- ryan_lane 3y agoHave you? Your comments don't reflect the points the book is making; in fact, they're counter to them.
- flygurl 3y agoThat applies far more to going from 10 to 20 than 1 to 2.
- ryan_lane 3y agoIf the project isn't parallelizable, it doesn't matter if you're adding 1 or 10, it's going to slow things down. Even if the work is parallelizable, if you add 1-3 people after the project is already delayed, it may still slow the project down, especially at first, because each of those people are going to need to be brought up to speed. Depending on the complexity of the task, the experience of the people, their understanding of the project, etc, it can either help or harm the project. There's a lot of nuance around whether or not adding folks to a project will make it faster or slower, and that's what the book is emphasizing. It's not a hard and fast rule of "don't add people to a project". The parent's comment didn't have any of that nuance. Just "more people can help spot errors and help with design" and the only issue they mentioned was "if they can avoid fighting". Neither of those things are what the book describes.