Incidentally, Steve brought up an interesting topic. Musicians practice by playing fast, then slow, then medium. Fast, slow, medium. Over and over. That seems like a good way to write software.
You first try to implement your idea as quickly as possible, stopping to think only when necessary. The goal is to not spend too much time overthinking the implementation -- you want to find out if your idea is worth executing on.
If you decide that your idea isn't worth it, then you move on to your next one. Otherwise you take it slow, going back over your code and refactoring it. (I personally don't believe in "make one to throw away", but rather that it's possible to refactor an ugly design into a succinct one.) At this stage, you should meditate on the best way to accomplish your engineering goals. It will pay off in the long run to spend extra time here.
Then comes the final stage in your project's lifecycle: medium. The core structure of the design has solidified, and you need to add the flourishes that make software truly great. But you have to take your time to ensure that the codebase stays clean. At this point, the design of the various smaller subsystems should flow naturally from the architecture you decided on in the "slow" phase.
Repeat for each core feature.