Beginner programmers are attached to their code. REALLY attached. After having been programming for around 10 years I realize that the way for me to write the best software is to work more like a painter. A painter might do 10 or 20 sketches before actually moving on and painting a portrait. The painter may review some of these sketches and take elements from them - maybe in one study, the chin was more accurate, maybe in another study the ears came out perfect. The painter will use these sketches as a reference as he works on the final portrait.
I do the same thing with programming. If I want to program something complex, I’ll do anywhere from 3 to 6 studies/sketches. These code sketches are usually messy quickly written code. The idea is to get my head wrapped around the problem. It isn’t until I feel I have a good grasp of the problem that I go ahead and try and tackle it. Even then, when I hit a wall I’ll often go back to sketching mode.
The main requirement for this approach is time. You need to make sure your client understands right off the bat that programming software isn’t a speedy process.
This technique is nothing new, there are variations and fancier names for this kind of thing… I just thought since I find myself telling this to my students all the time, I’d write a quick post about it.