Programming is slow going -- not inherently, only because people only attempt to do things grander than what's been done before, so nearly every project is by definition large and ambitious.
Any large project has a "momentum" element to it. The correct parts are assembled; humans spend time thinking through the implications of various technologies, approaches, and designs. Programmers despretely try to keep thousands of relavent details in their head as they write each line of code, never forgetting any of the implications even for a second for fear of introducing a bug. Get the technology, approach, or design wrong, which is inevitable to a degree, or fail to anticipate an obsticle, and you have to change directions and do rework. In the extreme but common case, you never approach the goal because each direction change also proves wrong.
Given this, there are two ways to manage a project.
Full throttle. The project manager knows where the goal is, and makes radical maneuvers to reach it, reassigning people willy nilly, readily throwing away what was highly desirable only moments ago. Anyone involved in the process quickly recognize the general flailing about as desperation and lose confidence, retracting their supporting, generally silently -- amdist the flailing, the project manager can't tell the difference. Full throttle looks a lot like 30% throttle when you're on ice.
Easy does it. Progress is intentionally slow to maximize the time available to react to obsticles as they're identified and minimize the amount of maneuvering needed to avoid them. Nearly all progress is preserved, albiet with minor tweaks now and then, and each reaction is fine tuned with the results of the previous reaction for calibration. Focus is on dedication to the current path rather than disposing of it for a path that's only hoped to be better. Movements build confidence rather than destroy it. The speed itself, like the path, is intentional, being adjusted, only slightly, up or down to balance feelings of lack of progress with feelings of lack of control. It's established from the start that the road is tricky and navigating it will take a certain amount of time, but the early admission makes people more comfortable with the idea of steady progress as an alternative to radical misses.
Obviously this doesn't apply to projects that can't be described as "large". If the goal is within reach, grab it! But the 1. Bring in lots of people and technology 2. ?? 3. Profit! designs dont' lend themselves to just reaching out and grabbing it. It's the route that needs some kind of strategy.
Successful projects follow the slow and steady wins the race strategy. OSX is NeXTStep and Mach, with Mach being work done on BSD Unix with parts of BSD mixed back in. The effort was stopped and started but worked on in some form or another for 30 years. Slow and steady most certainly won that race. But Microsoft has won a lot of races too (and even has market momentum, which isn't the same as development momentum). They kept working on PowerPoint even though 1.0 (and 2.0, and 3.0) sucked eggs. Same for Microsoft Word, and same for everything else they did. MSIE basically didn't exist in version 1 and 2 was about on par with Notepad and soundrec and the other programs that came with the thing, but MSIE 3 started to turn into something and people actually used 4. If they'd correctly identify the excessive baggage (especially in the form of backward compat with pre-Internet designs) as the real cause, they could make slow but stead progress towards security, but they seem to be taking a radical corrective maneuver, missing the target and damaging development momentum in the progress.
The legendary AmigaOS wasn't written from the ground up -- it was an old british mini computer operating system written in B (though the graphics and sound hardware were from scratch).
There are counterexamples, of course. I didn't mean to start writing how to go about predicting winners or anything like that... just writing to formalize my ideas of how management should proceed once given a task.
-scott
