I think that this is precisely the thing that silver-bullets like Agile et al apologize for:   “you realize that you’re building the house on-the-fly, just like you’ve always done, therefore, just keep doing it.   After all, you wind up with a visible structure that much sooner ...

After all, software development is so different from anything else that we have done throughout all of human history, “it must play by different rules.”

After all, users really won’t mind if the project is “a little late,” because they can plainly see that we are hammering nails and cutting boards as fast as we are able.

(thin smile...)   If only it were actually “a little.”

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.”

z - e - r - o .

You know, there is really nothing complicated about writing, say, “Perl code that works.”   Writing the stuff is actually not complicated at all.   Building a test suite is also not very complicated if you are building it from a pre-arranged laundry list.   No, I submit for the consideration of the Monks that the reason why software projects so consistently overrun, in every possible way and at sometimes awful cost, is that we are making the stuff up as we go along, and we are making excuses for shoddy (non-)engineering practices that would never pass muster in any other engineering discipline.   Computer software is punishingly intolerant of this, because it is composed of thousands of moving parts.   And yet, we do it, and we insist that we must.