Of course, it depends on the size of the project, but I usually do something similar. I think of what my program needs to acomplish, but usually don't write it down for most tasks(but that's just my style; I have a good memory). I think of some options, well many admitingly, before I begin coding, but I don't implement them untill I have the basic code working.

I started in C/C++ studying OOP, so as a result, most of my code is well encapsulated, and easy to adjust and add features to. I like to design my programs by what is called a "bottom-up"(as opposed to a "top-down") approach. This means that I first design the functions, and make test drivers (simple code to "simulate" what the main program will do) which test the functions and make sure they do what they're supposed to.

From the drivers, it makes it easy to see what's going on at an early stage, and to adjust the algoritms and logic accordingly. Once I've got all the functions all working as they're supposed to, I combing them together and work on a more permanent main program(I guess I call it that since in C/C++ it is called main :)

That's just my personal approach, but for me it works best because it allows for easy and quick updates and it doesn't require a lot of debugging all at once(because that's what I did all along with the test drivers). It also, because I tend to encapsulate the data anyway, makes it easy to change the code into a module, if need be.