Laying bricks scales somewhat linearly. If one guy takes 4 weeks to build a house then you can add three more for a total of four people and expect the work to be done in 1 week. This works across a lot of different tasks and areas, but of course not infinitely. If we keep adding people then at some point they will get in each others way and the benefit will diminish.
But for some types of work adding people not only does not help to have it completed faster – it actually takes longer to complete.
If we need to translate a book, then up until the point where the distribution and merging of individual words takes longer and gets more complicated than the translation itself we can keep adding people and expect a benefit in terms of finishing faster.
If we need to build a new motorway, then we can keep adding people and machinery to finish faster until it takes longer to deploy them, than the time it takes for them to pave any stretch of road.
In the physical world it is easier to keep within the boundaries of scaling and adding man-power to finish work faster. Either because it is blatantly obvious that you cannot have one stonemason per brick when constructing a house or because the cost of scaling would keep you from ever reaching the point where adding more would be detrimental.
The same sadly is not true when it comes to software projects. I suspect that it is a rarity to see a construction projects with too many employees. But that is no rarity with software projects. A lot of projects have too many people and when deadlines appear they will make it worse by adding even more.
There is a good old saying:
What one programmer can do in a day two programmers can do in two days.
It is a funny saying, but over and over it proves itself correct. And just spend a moment contemplating what it says: By adding people you are not only not finishing faster you are actually finishing even later than if you had continued with the original staffing. That is quite the statement. But sadly very true.
Software projects scale non-linearly as they have "fuzzy boundaries" and involves a high degree of creativity and novelty.
So what do I mean by "fuzzy boundaries"?
Let us return to the example of building a house. We imagine that all the outer and inner walls have been raised. From this point it is quite easy to imagine that we can have at least 1 painter in each room without them stepping on each others toes. They have clear boundaries materialized by the walls of the room.
"Fuzzy boundaries" can – keeping with the analogy of the house – probably best be personified by the electrician. If we have 8 rooms in the house and put 8 electricians in there it will be a total mess. Chances are that they will get in each others way, trip over or queue in line at the main fuse box and slow progress down substantially. Even though they each have their clearly defined physical boundaries, given by the room, they still need to interact with the same network of wires as everybody else and connect to the same fuse box as everybody else. 1 or 2 electricians will probably be the optimum number as they can actually help each other instead of getting in each others way.
The same rules apply for software projects.
There is an optimal number of developers, which is probably lower than you think, but almost impossible to foresee or calculate as it will depend on the product, the code base, the project and the team/company structure.
The clearer the boundaries; area by area, service by service, frontend vs. backend the more people you can probably use. But my advice would always be to error on the lower side. It is better to have too few people than too many. Projects with too few people will finish faster than projects with too few people.
When push comes to shove and deadlines appear, fight the temptation to "act" and add more people as much as possible. Have it be the last resort and only if rewards are to be reaped in the long run and not for short term goals. For short term goals adding people will only make it worse. You are behind and will not finish in time – accept it and have people do the best they can to finish as fast as possible. Do not make it worse by adding additional people and finishing even later.