>Remember, in analysis and design, the sooner you start coding, the longer you'll be coding.

I think that this statement is antiquated. The speed with which we can put together apps now makes it so. If your design methodology is correct (encapsulate business logic away from the UI), then I believe you can code now, think later.

With my framework (and most commercial frameworks) I can put together a prototype application with no "hardcore" functonality in a matter of hours. Often this is much less time than it would take to put together a formal "spec". Having something a user can see and feel also makes it a lot easier for the user to verbalize what his requirements are, and makes it easier for you to run your app layout philosophy by the user.

When I am working with a client to design a system, I often throw forms together during the meeting so the user can say "yeah, yeah..." or "well, that's not really what I had in mind....". This is an incredible time saver, and drastically reduces the need for later revisions because of misunderstandings.

The tools that we use change the rules for the Systems Development Life Cycle. If your programming tool of choice is easier and clearer than your flowchart software or planning software, use it instead.