I was pondering this today while wielding a shovel to bury the drain pipes that hang off my rain gutters (new house and all, this is the kind of crap I get to do with my weekends). Shoveling is one of my least favorite activities, but it is simple enough to allow the mind to wander.
I was trying to pick out some things that I have been prone to do in the past that has hindered my performance as a developer. One of these things is the need (arrogance?) to code things proper on the very first try. I don't know how many out there are like me in this respect, but I absolutely hate to have to perform a given task twice. While this coding "laziness" does inspire one to come up with the best possible design up front, I found that this can be damaging when you are entering a new problem domain.
Case in point, I'm working on a call tracking system right now that allows sales reps to gather information but also requires them to run through a preset script with responses they can select to load additional scripts... up until now, I'd never really thought about a system like this. In my youth, I would have sat and agonized over how to properly architect this, ultimately coming up with a design that would probably have some holes in it or not be all that great from a user experience perspective. This agony was from the hesitance to throw away any work I had previously done.
Instead of this attitude, I have embraced the attitude for this new domain that I am perfectly willing to trash as much code as is necessary to get this right. By using some of my codesmith templates and the RAD tools of visual studio I am able to rapidly prototype bits of the system to get a better idea of the gotchas whether they are in the UI or in the business logic. My first week on the project was spent taking the limited requirements and spinning them into asp .net user controls which I dropped into some test forms in various ways until myself and the end user manager were satisfied with how things were working out. Then I went back in the second week and ripped out most of the RAD stuff and dropped in cleaner code that follows our internal patterns.
Rapid prototyping is an excellent way to learn about a new problem domain. It's definitely not a cure-all as when you're on a tight timeframe and tight budget the extra time may put you into the red zone. In areas where I have good domain expertise I rarely prototype at all.