First I get some sort of framework in place where development is quick and enjoyable... whether that be having an IDE set-up for the project, or setting up __au

First I get some sort of framework in place where development is quick and enjoyable... whether that be having an IDE set-up for the project, or setting up __autoload() in PHP so that I don't have to put requires everywhere.. I just want to be sure I can code and not be distracted by overhead issues unrelated to the problem at hand. As per the actual coding, I agree with pg on this. I divide the problem into "sub problems," often sketched out in pencil with flows for certain things (and maybe corresponding UI's, if it demands). I choose to start work on either the most important (central) process, or often the most interesting one (to get me warmed up and enthused about the problem). Once this is done, it's a matter of branching outwards from that process, and optionally filling in UI's corresponding to that process. Along the way, refactors are inevitable, but most of the time I find I wouldn't have been able to predict them even if I'd initially spent a large amount of time doing conceptual models. I find the things that take the most time are the unexpected things, which I won't find out about until I'm coding it. The one thing I enjoy most about having the process sketched out is the options it provides. For me, it's not so much the issue of coding that is the challenge, but giving every aspect of the project the attention it deserves, without getting too bogged down on devoting too much time to making one part really awesome. When I see all the work that needs to be done, and what's related to what, I realize the scale of the sub problem I'm working on may not be as profound as I'd like it to be.