The sin code-generators commit

Tweet about this on TwitterShare on FacebookBuffer this pageShare on RedditShare on LinkedInShare on Google+Email this to someone

We recently had a lengthy discussion on my failure convincing students about the wonders of code-generation tools. A lot of pros and cons of code-generators were raised in the discussion but I wanted to comment on an important one that I feel it was overlooked.

In theory, the most important selling point of a code-generator is the possibility to forget about all the technical details and focus only on the modeling activities while the code-generator tool takes care of all the rest. By all the rest I mean the generation, deployment and execution (either via model interpretation over compilation) of the software you’re modeling, many times by means of an embedded web server in the generator tool (so that you don’t need to separately install and configure that). This way, supposedly, even non-technical people (whatever this means) can have the chance to participate in the software development process.

This is more or less true (again, refer to our previous discussion for more on the “less” part) when things go well and in one click you can usually go from a model to a running application. But when things go wrong, you’re on your own.

When, for whatever reason, the generated software does not compile well, can’t be deployed or generates a run-time HTTP error, the magical abstraction layer provided by the generator tool disappears and you are faced with some kind of unintelligible (for non-experts on web development) error message from your web server complaining, for instance, about a method that can’t be found on a class that you’ve never seen (because it does not directly correspond to one of the classes in your model but to an auxiliary class created as part of the generation process, giving you no clue on how to fix that).

If we want code-generators to be really usable, they should be able to hide not only the technological details but all the problems coming from it, digesting low-level error messages and presenting them in a way that makes sense at the model level so that the same non-expert that specified that model can now fix it.

Obviously, this is not easy, we know that all non-trivial abstractions, to some degree, are leaky (the law of leaky abstractions).

Tweet about this on TwitterShare on FacebookBuffer this pageShare on RedditShare on LinkedInShare on Google+Email this to someone
Comments
  1. Lee Riemenschneider

Reply

Your email address will not be published. Required fields are marked *