Q:

Design or prototype first? 

When first approaching a project is best to step back and think through everything or just dive in and start coding and polish at a later date?  Essentially, do you design first or try to rapidly prototype? 
I have been burned by both methods, sometimes I try and think everything through but when I actually get down to the nitty gritty I encounter problems that I didn't take in consideration, and sometimes when I code first I end with code that needs to redone to fit in with a better overall design.  Alot of my problems stem from inexperience, but any advice is welcome. 

A:

Go incrementally and iteratively. 
Design a bit, implement a bit.  
Starting with a design you can suffer from a tunnel effect where you cannot have any real feedback before you actually implement something.  
Starting without design, you can take decisions you'll regret.  
The ideal situation is to be able to implement a very skeletal end-to-end version of your system that can be tested, and demonstrated to the customer.  

A:

It is always safer to design first, but this does not mean prototyping does not work.  The real problem with prototyping is resisting the urge to keep the code you already wrote instead of throwing it away when the time comes to do the design. 

A:

There is no silver bullet.  It seems like design first is the preferred approach.  But you will not be able to predict all complications that can arise while implementing your design.  Some of them could potentially be show stoppers.  Plus, if you're writing for a client, it's good to be able to show something just to make sure that you're on the same page. 
At my workplace we do both - we do a rapid prototype, just to get feedback and get an idea of any potential problems.  Then we do a formal design and formal implementation.  In most cases we are able to salvage a lot of code from the prototyping stage.  I like this approach, since we usually end up with clean, maintainable code.