I think you missed something. There is a HUGE communication overhead in writing code with multiple developers. HUGE. If you have Bob writing a program all by

I think you missed something. There is a HUGE communication overhead in writing code with multiple developers. HUGE. If you have Bob writing a program all by himself, he writes at speed X. Now you add Jim. Jim is just as smart as Bob. But he doesn't know the way the object model works. He doesn't know about the glitch where sending null to some method causes a really weird stacktrace that is hard to debug. He doesn't know that the reason Bob did something else was to cover a real but rare network event. So Jim makes mistakes. Jim and Bob have to discuss decisions. Jim and Bob need to have meetings, and design reviews, and repeat mistakes. So I bet the total code delivered by Bob + Jim is something in the range of .9X to 1.1X. NOWHERE near 2x like linear scaling would deliver. You can argue something like the total code quality improves with more eyes, fine. But Bob is held back a lot and able to write a lot less code because of the newly added teammate. This is why some of the most influential pieces of software ever written were done by 1 man teams. A decent 1 man can be much much more efficient than a 2 man team. So back to your example. Bob goes halftime, and you are right - his productivity drops from X to .6X (not a full 50% loss, because his brain is more rested). But adding in Jim, you don't get .6X + .6X.. you get more like .5x-.7X total productivity. Adding a third Billy, and you end up with maybe .8X the original Bob speed. Remember you now have 4 people. So you need 4 way meetings. Each person picks different parts of the codebase to specialize in. People now write code that will conflict with other people, maybe not even knowing it for months. Maybe a forth programmer Jen can get your total productivity back to the original X of just Bob. So you know took 4 half time employees to replace 1 full time employee. All of this is why I think a team of 2 is almost always a mistake. A team of 1 can go pretty far, and when it hits a wall - it may be time for a team of 3 or 4. Team of 2 has all the downsides of a team (communication overhead, etc), with not enough bodies to rocket the project.