Is There a Place for Code Generation in Your Tool Kit?

I’ve discussed more than once in this space the fact that you’ll never reduce software development to some kind of mechanical exercise. I’ve even gone so far as to question software gods like Charles Simonyi, who seeks to systemetize software specification to the point that producing actual software becomes a push-button operation.

Is there a flip side to this, though? Even though I regard software development as a craft, implying that a craftsman is indispensable, isn’t it true that even a craftsman sometimes uses machinery to crank out simple components?

There are certainly pieces of many software systems that can be templated, or at least largely so. Data access layers are an excellent example. I wrote my own code generator about three years ago for a DAL I built for a large and complex application; if I were doing that project today I would have several mature products to choose from to save me the trouble and probably do the job better. At a higher level of abstraction, Iron Speed Designer is an example of a product that can generate pretty reasonable and maintainable CRUD-and-report centered web applications right from a database schema. All of these things have their place, in theory.

And yet … most code bases I see are hand-coded in these areas. Rightly or not, developers feel that the problem domain they are working with is special enough to require these kinds of things to be hand-coded. Or at least, they feel that committing to particular code generation tools will end them up in a straight jacket from which they can’t extricate themselves.

Often the generated code is over-engineered and over-generalized so that you really don’t have the option of cutting loose from the code generator and going your own way with it, because it’s hard to work with that kind of code by hand. Code generation tends to be an all-or-nothing proposition, and developers rightly hesitate at the brink of commitment.

Over at Metracircular, Warren Henning, connoisseur of less-than-mainstream languages, confesses that he’s run up against a brick wall trying to build a code generator using the functional language Haskell. To get a final result that’s really fit to a niche and with a quality UI, he found that as much effort goes into writing a functional spec as goes into woofing out the code by hand. It’s true that you can create ugly, unimaginative and inflexible applications from relatively small inputs, but he’s found that the devil, as always, is in the details. If you want something that’s actually compelling, the amount of effort to declare it in some generic functional form goes up exponentially.

Of course, anyone who uses a visual editor to lay out a user interface is using a code generator. Usually whatever is kludgey or ugly about such code is more than made up for in labor savings plus the fact that working with it visually is so handy that you don’t really need to even see the generated code.

But there are other things, like the typed data sets in Visual Studio, that don’t seem compelling to me, and some things, like dropping command objects onto forms, that are downright Evil for anything other than quick and dirty prototyping.

I keep promising myself that I’m going to write little code-spewing robots to speed up development, but there never seems to be a compelling use case or enough time. Maybe I’m missing something here. Do you have a success story to share about ways — even small ones — that you regularly use generated software artifacts beyond what comes with your development environment?