You seem very narrow minded. For some reason, you are incapable of understanding that what I am saying is not that such problems should be solved by brute force. What I said is simply that if you have one guy loaded with work that would normally require five people, hiring more coders is not trying to solve the problem by brute force, it's just having the adequate workforce to complete the job, in order to have acceptable working hours. Why I say this? Because this happens all the time. People are often loaded with way more work than they can actually do. And the reason why the aphorism is not appropriate is that while you absolutely can have more people working on the same code, you can't have different women giving birth to the same child. So no matter how hard you try to spin it, in this specific context the aphorism is not that appropriate.
I never said that most of that 80 hours is spent typing on a keyboard. However, whether they spend most of that time typing on a keyboard, smoking pot, dancing in circle or having a wild party with a topless waitress is not really the point here. The point is that the same job can either be completed by one guy working 80 hours a week or by two guys working 40 hours a week, with the difference begin the amount of individual workload.
There's been a ton of research done on the subject of software development management, and it's generally accepted as fact that work done by a coder is not linearly divisible amongst multiple coders.
While, if you assume every coder has the same expertise, thought process, and familiarity with the code, yes maybe you can divide work easily. But add in the politics, reiteration, and the sheer size of a rapidly expanding code bank, and splitting work mid way through a development process will not halve the work of each developer.
Will it reduce workload? Maybe, but not too a point where it's financially reasonable to hire more people.
There's a lot more going on behind the curtains besides technical skill that slows down software development.
For example, let's say you're a baking a cake for someone. You're really good at baking chocolate cakes, so you get started on it. Halfway through they tell you they want a double decker chocolate vanilla cake with fruits on top, and the bottom layer being chocolate with the top layer vanilla. You don't have all the ingredients, so you ask your friend who also knows how to bake cakes to start working on the vanilla layer while you get missing ingredients. You get back and you find that the consistency of both layers of cake are different and you both need to find a way to fix this problem without making a new cake. You toil over night with your friend to figure out a proper recipe.
In the end you get it done, and the cake looks and tastes nice enough, but it probably would've taken as much time, if not a little longer if you just did everything yourself.
Does the example seem convoluted to you? Good. Cause software development is a complicated and somewhat unintuitive process, and my example is an over simplification of what can potentially happen.
The point people are trying to make as a response to you is that development isn't scalable. And the deeper into the process you are, the longer it takes new people to work as efficiently as old people. A job
can't be completed by two people working 40 hour workloads than one person working 80. Not unless the one person working 80 was never a thing to begin with, and you always had 2 people doing the job. But hindsight is 20/20 and there is no way to know that before it actually happens.
