Reinforcing the Mythical Man-Month
There's a very interesting book called The Mythical Man-Month and the crux of it is that there is no such thing as a mon-month. You can't look at a project and add "units" of work and assume that it will linearly scale. It just doesn't work that way. Well, today I had my own reality check with just this proposition.
While I don't have accurate numbers, I'm going to give ballpark estimates to illustrate the point. You have three developers: Steve, Ted, Bill. Steve is the best and can deliver about 1000 lines of debugged code a day. Ted and Bill are junior guys and are in the 100 lines of code a day range. They wrote decent code, but not as good as Steve's, and not nearly as fast.
Give Steve a project that he can finish in a week, that's 5000 lines. It'd take Ted or Bill ten weeks. The "mythical man-month" says that if you add Ted and Bill to Steve's project, it has to get done in less than a week. Yet when you do this, it takes longer than a week. Why?
Because Ted and Bill are pulling Steve away from his work. He's no longer capable of 1000 lines a day - maybe only 500 because he's spending half his time answering questions, re-writing code, checking compiler errors for the two guys that don't know how to perform at his level.
Is this bad? No. Unless you want that project done as quickly as possible. It's the process of Steve imparting some skills to the junior guys. It's great if there's time. But in this example, adding Tim and Bill to Steve's work is going to slow him down to 500 lines a day, but these other two are only adding 100 lines each - so the combination is only 700 lines a day -- a reduction of 30%.
So if you think you're going to speed things up, follow this rule: Never slow down the top performers. Never. It's not the time to teach, it's the time to get things done. If you want to teach, take the time to do it right, but don't put the team on a tight schedule.