Quick and Dirty On Wednesday, January 30, 2008

Labels: None  

Of course, "exploratory programming" is just a euphemism for "quick and dirty" programming. And that phrase is almost redundant: quick almost always seems to imply dirty. One is always a bit sheepish about writing quick and dirty programs. And yet some, if not most, of the best programs began that way. And some, if not most, of the most spectacular failures in software have been perpetrated by people trying to do the opposite.

So experience suggests we should embrace dirtiness. Or at least some forms of it; in other ways, the best quick-and-dirty programs are usually quite clean. Which kind of dirtiness is bad and which is good? The best kind of quick and dirty programs seem to be ones that are mathematically elegant, but missing features-- and particularly features that are inessential but deemed necessary for propriety. Good cleanness is a response to constraints imposed by the problem. Bad cleanness is a response to constraints imposed from outside-- by regulations, or the expectations of powerful organizations.

Arc's Out by Paul Graham.