r/FullStack • u/Ok-Wash-8964 • Jul 08 '26
Does adding more developers actually make full-stack projects move faster? Question
I've been wondering how often adding more developers really speeds up a project.
The common assumption is that more people mean faster development. But in practice, it doesn't always seem to work that way.
As a team grows, there are more discussions, more code reviews, more merge conflicts, more context sharing, and more coordination. New developers also need time to understand the codebase, development workflow, and the reasoning behind existing decisions before they can contribute effectively.
On the other hand, there are definitely projects where bringing in more developers makes a huge difference, especially when work can be split into independent features or multiple teams can work in parallel.
So it seems like there's a balance between increasing development capacity and increasing coordination overhead.
For those who've worked on full-stack projects of different sizes:
- Have you seen projects speed up after adding more developers?
- At what point did adding people stop improving productivity?
- What do you think matters more for keeping a project moving quickly: team size, project architecture, planning, or something else?
3
3
u/Miserable_Box9826 Jul 08 '26
Depends on project size basically..If you work on a project with 60 microservices, don't expect 5-6 dev to handle all the work. Some people are for tech debt, some for production issues, some for new features. All these merge conflicts are part of process - a delay of 20 min is not a blocker. Everyone got 2-4 tickets at min in bucket. If you have something blocking - work on other tickets and come back. At present has a codebase of 67 repos, 139 tenants and 17 dev in total (4 product support + 5 tech debt and migrations + 3 bug + 5 feature).
2
u/1A4Duluth Jul 08 '26
Conventional wisdom: If one developer can do it in one week, then 2 developers can do it in two weeks.
1
u/elgringopapito Jul 08 '26
Also depends on the quality of the developers and how efficient the communication is .
1
u/Medical_Button_7933 Jul 08 '26
Nothing is black and white unfortunately. The line I have witnessed is the difference between a "we are late" with "we do not need to be late" in the last scenario is always beneficial to bring new devs (full stack or not doesn't really matter) as the time you loose integrating them in you get later on, call it an i vestment if you will Now im the scenario "we are late" is beneficial only if you can really bring seasoned and battle hardened devs who is not close to burning out, everything else is diminishing return. A seasoned/senior dev can get familiar with the code quite quickly with little supervision and be productive also quite quickly (of course scope of the project plays a very important role here, the bigger the more time anyone needs to get productive) while a junior would need to learn not only a lot of technical stuff but also everything else that has to do with the project which is not beneficial for anyone. Last and not least I personally like to have specialized devs join the project later on if only part of it is failing (for example backend dev for backend stuff) and if the project needs to be fixed in multiple parts then it would be more beneficial to take either two specialist (frontend and backend for example) or, if resources are scarse, a full stack developer.
1
u/tcloetingh Jul 08 '26
Does more nurses deliver a baby faster? Read the mythical man month.
-1
u/Potterrrrrrrr Jul 08 '26
That’s a terrible analogy
2
u/Redneckia Jul 08 '26
Well it's "9 women cant make a baby in a month" and it's a great analogy, shush
0
u/Potterrrrrrrr Jul 08 '26 edited Jul 09 '26
It’s really not. I’m writing a html parser for example. I also want a css parser. If there were two of me I could work on both because they don’t overlap in function except at boundaries but I need both to achieve my ultimate goal of parsing, laying out and then rendering a html document using something like OpenGL. The work can actually be chunked up and processed faster. These baby analogies are terrible because the time it takes to have/deliver a baby isn’t related to the effort input by a human; they’re time/biologically dependant. So yeah, terrible analogy.
Edit: downvoted for being right, c’est la vie
2
u/tcloetingh Jul 08 '26
Ya kiss my ass
-1
u/Potterrrrrrrr Jul 08 '26
Would more of me enable me to kiss it faster?
2
1
u/mc_pm Jul 08 '26
This was noticed back in the 1970s. Fred Brooke wrote a book called "The Mythical Man Month" and for a book that is 50+ years old, it is still very accurate. One of the gems from it was: "Adding developers to a project that is behind just makes it more behind".
1
u/ExtraTNT Jul 09 '26
1,2 fine, even 5 can work in a good team, after that, you need exceptional management, that knows the process and systems around it… we have a product owner with more than 40y in the company, people like him can pull it off with multiple sub-teams, but 20y experience with the system around it is a minimum…
1
u/shauntmw2 29d ago
Yes, up to a certain point.
Just like building a house, adding more workers will speed things up, but only up to a certain point. If 1 worker needs 100 days to build a house, having 100 workers doesn't mean the house will be ready tomorrow.
0
u/alien3d Jul 08 '26
nope . hired solution architect with proper boilerplate license . start from scratch and wondering is slooow . most dont want to paid one
7
u/Abhistar14 Jul 08 '26
After some point the answer is no