Why do large companies think that throwing more people at a project will help get things done faster?

Ironically - its had the adverse effect on the project I'm currently on.

Nine pregnant women can have a baby in one month!

@bahua lawl

Usually, that's the case, assuming the project, the team and the tasks are being structured properly.

Usually that’s the case if the new joiners are aware of the requirements or can onboard quickly and get up to speed. In reality from my experience putting more people to speed up delivery just creates a big mess where people are stepping on each other’s toes

@PappyHans 100%

@netikras and the project lends it self to parallel work.

But there’s always a limit when more people do not increase speed and where it might actually harm efficiency as synchronization takes more time than the extra hands add or when things have to happen in order.

Because they only see numbers, not the actual tasks and how they depend on each other.

You have to build the wall before you paint it and the paint should dry before you start placing furniture.

But on paper its just a number of hours of work and a number if workers doing hours.

@Voxera That's absolutely what it comes down to.

I like to compare software to mathematics. They're completely different but it's like if you were to erroneously compare software development to mathematicians at a university.

"OH, you solved 3 equations last week but only 2 this week? Either you're slacking off or you need support - here, have a few more mathematicians"

@bahua Came to make sure this was posted. Carry on.

I also like "What one developer can do in a month, two developers can do in two months".

Of course there's a big fat "it depends" in there, but strictly in terms of speed - if a new feature is estimated as one month for one person to research, design, implement, and close, you are absolutely not going to get it done faster with more people. You might get it done in a similar time, but that other person has to be taken from somewhere.

Perfect team for me is 3 engineers. One senior, 1 dev and 1 junior. If the project is too big for three, divide and conquer and make new teams. If you need a meeting the team is too big for my liking. My current team is 2 and we have achieved at least double what my previous team of 5 were managing.

@lechuckles LUL - this resonates with my project. One team of 4, one team of 3, originally was efficient - project started to run out of money - hired less than sufficient developers = why are there so many bugs now?!?!!

Nothing ironic about it.

It's a known phenomenon for ages:

"adding manpower to a late software project makes it later"
-- Fred Brooks, 1975
https://en.wikipedia.org/wiki/...

Whenever I am a new person on a team or get new people in my team, I always ask the people in charge if they are aware that it will slow things down first. And most are very aware. So it appears that your management is not that great :D

@whiskey0 glad it's not just me ;)