Let's assume you're a pretty good programmer (and good looking to boot!). It's Monday morning and you're looking at a task that has some solid complexity to it -- it's going to take you 40 hours of effort to get through. Or you have the option of delegating components to 2, 3, or even 4 competent-but-not-exceptional developers. For these guys to deliver, you're going to have to:
- Decompose the task significantly
- Write a precise spec, at least for the initial subtasks (because if you get off on the wrong expectation of data structures, there's no way you're going to catch the problem, refactor it, and re-distribute the tasks)
- Engage in course correction (when facing ambiguity, "problem solving" for these guys is going to be asking you for clarification)
- Do some refactoring (let's face it, there's going to be a couple things that will be easier to fix than re-specify)
- Spend (at least) one afternoon on interactive testing and integration
(For "decompose" and "write a spec" feel free to interpret however you wish, so long as it's a concrete deliverable that acknowledges that if you're delegating and "fanning out" tasks, you have to pay an upfront cost thinking through scenarios that are still somewhat hazy and contingent.)
So here's my question: how many hours do you think you can shave off the 40 hours it would take you to "just do it" yourself? 8, 16, 32?
There are (at least) 2 points that strike me as relevant : one is that even in such a fine-grained, seemingly controlled, context you face significant "mythical man-month" issues of communication overhead, risk, etc. and so you discover, if you time it, that you don't save nearly as much time as you'd hope.
The second point that I think might be even more interesting is that your perception is likely to be even worse than what the clock says. If you are in this role, you will rarely or never get into a high-productivity "flow" state, a familiarity with which, I would submit, is why you're a pretty good programmer.