Wrong.net

No, really.

The usual analogy that we here is that software development is like building bridges.  This makes for a nice picture, with lots of little programmers carrying around bricks made of ones and zeroes.

But, it doesn’t seem to fit reality very often.  And attempts to build software in that way tend to have certain, repeated issues.

So, maybe, programmers are more like artists?  Sounds good.  But, what does an artist do?  How do they sit down and create a masterpiece painting?

The first thing that an artist will do is do some sketches - studies of individual parts of the final painting, some sketches giving the overall composition.  At this point, they’re trying out techniques, working through tricky areas, and deciding how they want the painting as a whole to look.

Some of these sketches may end up relatively detailed, but they’re all ultimately designed for one purpose:  To be discarded and thrown away.  None will be the ultimate painting.  They’re nothing more than preparation.

So then, the artist will begin by stretching his canvas, putting on a layer of primer/gesso (or not), and then generally doing a sketch right on the canvas.  This sketch is extremely rough, and is only meant to show the general size, shape, proportion and position of the final visual elements.  As the artist puts down these lines, he puts them down very lightly, until he has more confidence in the final placement.

Next comes the underpainting.  The painter will then work with (generally) a single color of paint at various dilution levels, to block in the large areas of light and shadow for the painting.  The painting will still have a loose, unfinished look about it, but the major forms will start to be visible.

As the painter continues, they will add in other colors, begin to add large details, and refine the painting.  Normally, they will work more or less uniformly over most of the painting - they won’t heavily favor one area over another, unless doing so is part of the composition.

To me, this is much more a description of the software development process than any engineering analogy.  When we write software, we first might make prototypes to test out individual concepts or systems, knowing full well that most of them will be thrown away.

When we start the program for real, it is generally best to start with only bare functionality in the basic systems of the application.  Not doing too much too fast leaves us in a better position to change our minds if we find we made a mistake.

As the application grows, we start more rigidly defining the areas, always taking care to look at the whole of the application instead of just the one part we’re working one at the moment.