[jrockway]

It does. I think apenwarr has a good outlook on this:

"maybe we can just have the engineers work weekends or something? Well, I think most of us know that's a losing battle. First of all, even if we could get engineers to work, say, on Saturdays without any other losses (eg. burnout), that would only be a 20% improvement. 20%? Give me a break. If I said I was going to do a talk about how to improve your team's efficiency by 20%, you wouldn't even come. You can produce 20% more by hiring one more person for your 5-person team, and nobody even has to work overtime. Forget it.

https://apenwarr.ca/log/?m=201712

[adrianN]

If only hiring 20% more people would mean 20% more efficiency we would have a lot fewer problems.

[jrockway]

Sure, but there are a lot of efficiency killers to look for before you need to worry about individual hours worked.

Adding 20% more people doesn't make the software come out 20% faster because:

1) Multiple people need to work on the same critical section of the code, and then there are merge conflicts. (Or people disagree on the design, or refactoring becomes a higher priority than doing what users want, etc.)

2) People work sloppily and omit relevant tests, only for someone else to have to re-discover the bug, fix it, and write the tests (trading productivity from one person to another).

3) People work on the wrong tasks, adding 20% more technical debt but not fixing 20% of the highest-priority bugs.

4) People take 20% less responsibility so you end up with "someone else will handle that (where "that" is usually documentation, monitoring, deployment, or anything else not explicitly captured in your list of bugs/priorities).

It is very interesting to me how internal software development often fails (I'm sure I've been the point of failure before), but software development CAN scale. I use AWS, for example, and I'm sure their software engineering teams are messing with products/features that my team uses. But they don't make me 20% slower. Ultimately, overly-tight coupling gets you every time. But on the other hand, too much isolation can also be a problem (time spent overengineering). If you find that balance, you can scale your team infinitely ;)