I have consistently found that, if you plan the project as thoroughly and as meticulously as you actually need to, the actual construction of the thing is, as I said, “virtually an afterthought.” It also enables you to say, and not only to say but to say consistently: “deployed on time, deployed on budget, zero defects.”

I have consistently found that the above paragraph is nonsense.

Now, when a task is small enough that I can plan the entire thing out in my head before I write a line of code, then yes, I can predict pretty accurately how long it will take and cost. But that's because, as someone said elsewhere in this thread, "planning" in the context of programming IS coding to a significant extent. If you're planning and thinking about the program in terms of code and algorithms, then once you have it all "planned," you already have it coded, except for the tedious typing. Of course you can provide solid deadlines and cost estimates then -- the real work is done.

But that just redefines programming as planning, in my opinion. How about if you're writing pseudo-code? Is that planning or programming? What's the difference? What if, instead of writing pseudo-code and flowcharts, I go ahead and start writing real code, tweaking it as my "plan" evolves? How do I tell when I'm planning and when I'm coding? Maybe you can plan a program fully without thinking through the required code (and database tables and so on), but I can't. I don't even know what that would mean.

Look at it this way: instead of comparing building a program to building a house in real life, compare it to building a house in a CAD package (apples to apples). You could plan the house out on paper, with lots of notes and hand drawings about what you want until you have complete blueprints, and then use the tools in the CAD package to "build" the actual 3D house, considering that a separate step from the planning. Or you could just start up your CAD package, load a basic template that has some algorithms you commonly use (walls, floors, roof), and then start adjusting and tweaking until you have the house you want. Odds are you'd do a combination of the two: maybe a couple quick sketches on paper to get the basic look in your head, and then start "building," working out most of the details during the building stage.

You condescendingly imply that we're being ridiculous when we say programming is different from "other engineering disciplines," but the fact is that programming is NOT engineering, at least not in the full sense of the discipline. Building ideas from smaller ideas is different from building objects from smaller objects, like it or not. It presents different pros and cons, and the fact that "planning" and "building" can be intermingled in a way that they can't be in brick-and-mortar projects is both pro and con. You can't get away from that con, so you might as well take advantage of the pro.