But after planning, there still comes coding.
I often adopt the approach of "code early, code often". I'm not saying that it's the best approach, but if you happen to prefer tinkering with existing code than staring at a blank page, it may have some attraction for you.
Once everyone's settled on the question of which pages are doing what, and I've figured out what each page will need to do to achieve it, figured out how the pages, classes, functions etc. will talk to each other - figured out the architecture in other words - I get coding.
Code Early
Usually, I've aleady written or sketched out a bunch of gadgets (or conscripted some I've written in the past) just to illustrate what some piece or other is supposed to do. If they do what they're supposed to, I use them. The rest, I just do what first comes to mind, on a piece-by-piece basis. Each piece is as independent of the others as possible (eg. "Global Variables Considered Harmful").
I don't go for elegance, or efficiency, or things like that; I just try and whack out something/anything that will work as the architectural plan advertises. If I do get a nice idea, but one that would need a bit of thought to code properly, I note it down in a TODO list and go for a more simple-minded approach. I use a linear list instead of a red-black tree; simple-minded translations of algorithms (or simple-minded ports of code from another language) instead of taking the time to write them in the PHP idiom or take advantage of how PHP operates.
It's at this point where flaws in the architecture show up. Fine: fix them (this may require massive reworkings from the ground up - I only hope I have the time) and repeat.
Hopefully that loop terminates after only one or two iterations. Usually two, but it still makes sense to try for one.
The result is (oh, frabjous day) something that works. Barks like a dog, heaves and pulsates convulsively, probably exponentially slow and greedy, but works. Deadlines no longer seem quite so critical.
Code Often
All these bits are independent of each other. I can mess around with one and, so long as it continues to work as advertised, I can do so with impunity. Rewrite it totally, if need be. Because the site is working, it can serve as its own test harness. I can see how all the bits are interacting in situ, and see which bits are the most in need of optimisation.
Iterate. Frequently. One change at a time: be suspicious of any need to change two components concurrently - that suggests they're not properly indpendent. It happens of course, without a doubt - changing a database table may impact on components that use that table (you know which ones they are - you're supposed to have documented them), for example - it's just that you should be cautious about doing so.
And don't be scared to trash even functioning code.
By "the end" of the process (with "the end" often being defined in terms of deadlines, although service agreements may allow subsequent opportunities for further tweaking) what's been written may only retain the architectural outline of the first working version, with almost all the actual code having been rewritten at least once.
Such is the origin of Version One.
In an ideal world, all the above works without causing any grief....
Now I gotta go, the men in blue coveralls are calling for me. At least, it's either them or the men in white coats...
