It’s called Brook’s Law. It takes a lot of time and effort getting people up to speed, and that takes experienced devs away from coding. You also have to get them credentialed, teach them the tools, need extra code reviews/testing/bugfixes while they learn the quirks and pitfalls of the code base, etc. In the long term you’ll be able to get more done, but it comes at the cost of short term agility.
If you have a troubled project, and you add more people, you have a bigger troubled project.
It’s a common trap for project managers … and in fact some pretty high brow projects blew up because of this.
When you are called in front of the board, and they say:
“Hey, your project is late, we get it, it’s not your fault, but we have to deliver on the 1st of the month. - and so we’re giving you our 10 best men to get it done”
I can tell you, it takes a certain amount of testicular fortitude to say “That won’t work”. More than I had at the time , in fact.
My anecdote isn’t quite the same since it deals with something a lot simpler, and lower stakes than stuff like this.
used to assemble bicycles for a sporting goods chain, and had to travel to a nearby city to build theirs because nobody there knew how. I had two days to get 300 done.
I got there and start, and about two hours in the store manager comes over and tells me he’s pulling 2 of their operations employees to help and learn how to build. “they’re the strongest guys we have so they should have no problem tossing these bikes around”
I straight up told him I have no time at all to train them on how to build and do the safety inspections correctly, not to mention the fact that I will still have to personally inspect every single one they put together anyway, so if they want to give me help I’ll take it but they’re on trash duty. Remove all the packaging, put the bike next to my work area, toss the trash. I will build. If there’s extra time at the end I will be happy to instruct everyone in the store how it’s done. Or even put me on the schedule for next week to do it.
Dude got pissy and wanted me to train people first, so I just called the district manager while he was talking and had him tell the guy to do what I said because I’m here at corporates request and if I don’t get the bikes finished in time then “it will look bad on your store’s next visit if the bikes are still boxed up”
In the end I got all of them done with about 3 hours to spare, so I spent the rest of the time teaching a couple people how to do it.
More like 12-14 hours, and with the experience I had I was able to build most in about 6-7 minutes.
There’s downsides to speed building like that, because whoever has to inspect it when it gets sold has to spend a lot longer fixing minor problems.
If I were building at my own store, each bike took about 20 minutes because I made sure everything was as close to “ready to ride” as possible.
Nowadays I bulk build for many companies. They don’t give a shit about quality but I spent years making sure my bikes were perfect, so I still like to make them good to ride out the door.
my quickest bike was one particularly well put together model. 3 minutes per bike and it was good enough that I’d ride one without tools to the nearest store a few miles away.
Big teams are faster on straightaways. Small teams go through the corners better. Upgrading from a go-kart to a dragster may just send your project 200mph into a wall. Sometimes a go-kart is really what you need.
Yeah, it happens everywhere, all the time. And the main cause of it is, surprise surprise, people who have no technical understanding of the subject matter.
Currently in a project, where for strategic and unrelated reasons, we ended up with 4 new juniors and had to hand off one senior. In a team that consisted of merely 3 people before.
So, it’s just me and another guy having to constantly juggle these juniors to push them back into the right direction and review whatever code they ended up with.
It’s so frustrating, because while I’ll gladly pass on my knowledge, the project has basically ground to a halt.
There’s so many tasks me and the other senior would like to just quickly tackle. Which should just take a few days, no big deal. Oh no, I rarely get a day’s worth of work done in two weeks. The rest is just looking after the juniors, who cannot tackle many of the actual crucial tasks.
And it’s not even like the juniors are doing a bad job. Frankly, they’re doing amazingly for how little support we can give them. But that doesn’t stop the project from falling apart.
Maybe “credentialed” wasn’t the right word. I was thinking of software licenses and access to third party tools and systems. Probably not as big a mess in game dev as it is in government.
It’s called Brook’s Law. It takes a lot of time and effort getting people up to speed, and that takes experienced devs away from coding. You also have to get them credentialed, teach them the tools, need extra code reviews/testing/bugfixes while they learn the quirks and pitfalls of the code base, etc. In the long term you’ll be able to get more done, but it comes at the cost of short term agility.
If you have a troubled project, and you add more people, you have a bigger troubled project.
It’s a common trap for project managers … and in fact some pretty high brow projects blew up because of this.
When you are called in front of the board, and they say:
“Hey, your project is late, we get it, it’s not your fault, but we have to deliver on the 1st of the month. - and so we’re giving you our 10 best men to get it done”
I can tell you, it takes a certain amount of testicular fortitude to say “That won’t work”. More than I had at the time , in fact.
My anecdote isn’t quite the same since it deals with something a lot simpler, and lower stakes than stuff like this.
used to assemble bicycles for a sporting goods chain, and had to travel to a nearby city to build theirs because nobody there knew how. I had two days to get 300 done.
I got there and start, and about two hours in the store manager comes over and tells me he’s pulling 2 of their operations employees to help and learn how to build. “they’re the strongest guys we have so they should have no problem tossing these bikes around”
I straight up told him I have no time at all to train them on how to build and do the safety inspections correctly, not to mention the fact that I will still have to personally inspect every single one they put together anyway, so if they want to give me help I’ll take it but they’re on trash duty. Remove all the packaging, put the bike next to my work area, toss the trash. I will build. If there’s extra time at the end I will be happy to instruct everyone in the store how it’s done. Or even put me on the schedule for next week to do it.
Dude got pissy and wanted me to train people first, so I just called the district manager while he was talking and had him tell the guy to do what I said because I’m here at corporates request and if I don’t get the bikes finished in time then “it will look bad on your store’s next visit if the bikes are still boxed up”
In the end I got all of them done with about 3 hours to spare, so I spent the rest of the time teaching a couple people how to do it.
Holy shit. In an 8 hour day that’s like 20 bikes an hour. So that’s a bike every three minutes. How is that even possible?
Lol I wish it was just an 8 hour day.
More like 12-14 hours, and with the experience I had I was able to build most in about 6-7 minutes.
There’s downsides to speed building like that, because whoever has to inspect it when it gets sold has to spend a lot longer fixing minor problems.
If I were building at my own store, each bike took about 20 minutes because I made sure everything was as close to “ready to ride” as possible.
Nowadays I bulk build for many companies. They don’t give a shit about quality but I spent years making sure my bikes were perfect, so I still like to make them good to ride out the door.
my quickest bike was one particularly well put together model. 3 minutes per bike and it was good enough that I’d ride one without tools to the nearest store a few miles away.
Often long-term agility, as well.
Big teams are faster on straightaways. Small teams go through the corners better. Upgrading from a go-kart to a dragster may just send your project 200mph into a wall. Sometimes a go-kart is really what you need.
I just wanted to say I loved your analogy.
Some go karts have 2 seats and that’s ok.
“What one programmer can do in one month, two programmers can do in two months.”
Yeah, it happens everywhere, all the time. And the main cause of it is, surprise surprise, people who have no technical understanding of the subject matter.
Currently in a project, where for strategic and unrelated reasons, we ended up with 4 new juniors and had to hand off one senior. In a team that consisted of merely 3 people before.
So, it’s just me and another guy having to constantly juggle these juniors to push them back into the right direction and review whatever code they ended up with.
It’s so frustrating, because while I’ll gladly pass on my knowledge, the project has basically ground to a halt.
There’s so many tasks me and the other senior would like to just quickly tackle. Which should just take a few days, no big deal. Oh no, I rarely get a day’s worth of work done in two weeks. The rest is just looking after the juniors, who cannot tackle many of the actual crucial tasks.
And it’s not even like the juniors are doing a bad job. Frankly, they’re doing amazingly for how little support we can give them. But that doesn’t stop the project from falling apart.
This, except for bullshit credentials.
Maybe “credentialed” wasn’t the right word. I was thinking of software licenses and access to third party tools and systems. Probably not as big a mess in game dev as it is in government.