software design sketching

Peter Lindberg posted some thoughts about the lack of "sketching" in software development, which got me thinking a bit. The following was my emailed response to Peter:

Personally, I do a fair amount of software “modeling”, in the form of prototypes. If an application calls for a new GUI component, for instance, I’ll set up an empty application/shell/playground with some “scaffolding” to provide the component with its inputs, then start “playing” with it until I find something that feels right. Sometimes it will be a continual evolution of the design in the code, but sometimes I’ll duplicate classes, and rename them with some sort of version ID in the class names, so that I can view several stages of the evolution at once.

The same applies to games I’m designing, or ideas I have for new applications, or, for that matter, changes I’m considering in the CSS code for a website. Seldom do I start off by mapping out “here’s exactly what I want to implement” in my own projects; Almost always, in work that I’m doing for myself, I start off with an exploratory phase just to see what comes out of my fingers, and after a few iterations of coding, and trying out what I’ve done, and sometimes putting the project away for a few days or weeks, eventually things tend to settle into a zone that feels right.

In a group effort, this doesn’t always work that well. When several people are involved from the beginning of a project, if everyone just spins off into an exploration of their own ideas, it can be harder to gather everyone back to some common point to get everything working together. Maybe that’s why software design tends, as you say, to be focused on “producing construction plans” and defining APIs for how modules will work together.