You missed the most important one: Make it run.

A program that meets 90% of its spec and takes a week to write is often more useful than one that meets 99% of its spec ("there is always one more bug") and takes three months to write. Basically, what I'm saying here is that your program should always work to some degree, so that you can release them to the users, get feedback on how you're doing (real-world specs are moving targets), and get part of the problem solved right now. If it's buggy, so what? Make sure your users know that what you're releasing isn't "finished", and make sure they know that you're listening to the bug reports.

I'm thinking of this mostly from the perspective of the tools I used to write in industry: data-munging scripts to save people hours of drudge work. In almost every case, I could get a large chunk of the problem solved in a matter of hours, and start saving my users time right away while working on the rest of the feature list. On the other hand, I think this works well in most other application domains, too. Let's say you're writing a dynamic, user-tracking website for tracking local bands and gigs. Don't wait until you have theme support and a spiffy forum to release the first version; let people start listing (and advertising for) gigs right away while you add to the feature set.

We'd all be pretty disappointed if vroom had waited until Recently active threads was implemented before going public with Perl Monks.