User interface generation tools are something that has always been dear to my heart. I've enjoyed using them and have been fortunate enough to work on developing them. However, there's a huge tar pit to be avoided when using them on projects that I see people heading towards over and over again.

The problem crops up when one tries to automatically generate GUIs from a model. It doesn't matter what the model is; once upon a time it was a CORBA IDL or a relational database schema, today it's more likely to be a UML model, WSDL schema, RESTful API, or whatever the API du-jour happens to be.

The tool is pointed towards the model's metadata, wizards are launched, and, hey, presto. Alakazam, a brace of fully compliable screens are kicked out in seconds. Things are looking good so far - the application can connect to the messy backend, the GUIs will list elements with trees or tables of child elements, windows are peppered with Add/Edit/Remove buttons, typed attributes are turned into appropriate controls, and it looks like the project is off to a flying start. But beware - this is the same false feeling of well-being that occurs when walking downwind of a fast food restaurant on an empty stomach.

The first problem is that code-generated GUIs are just that - they look and operate as though they are, well, generated by a machine. I feel strongly that GUI software is more art than science, and that the GUI is the most important piece of any application. Musicians use technology to create sounds; animation studios to give life to cartoon characters; however the software's job is to let the artist get on with the job and facilitate the task, not replace them.

The problem with code-generated GUIs is when changes are required. The tool either has a zillion code-generation options that have to be mastered to tweak its output, or more likely you have to tell your users you can't change something awkward or clumsy because that's how the tool made it. This frustrates any skilled GUI developer who looks at the generated code and knows he is perfectly able to change it, but it's forbidden because it can't be round-tripped and would break the link from the model to the GUI.

At this point a standoff occurs between those who think that the model is the center of the universe and those who think that the GUI is more important. I'm firmly in the latter camp - I don't dislike modelling, but it's just a means to an end. The GUI developer has to have total and utter freedom to design something that is totally unconstrained in how it looks or behaves, how it navigates windows, how it reports errors, and so forth.

This has happened because we as an industry create new API protocols so fast that application developers are constantly chasing a shooting star looking for delivery shortcuts. Projects that start out backing one particular language, platform, and backend often find that by the time they're ready to ship the industry has moved on and their once state-of-the-art software looks obsolete.

However, rather than take this approach, I believe that the best route is to hold to the course and focus on the usability of the application and have first-class UI designers on your project to create something that looks like it's been built by developers who care about their user's experience and the beauty of their user interface, rather than the underlying data model. There is nothing wrong with code generation tools, however they should be viewed as cheap furniture - they'll hold up for a short period of time after which they'll bend/warp and crack before they need to be thrown away.  Great if you have a system to build with a short shelf life, however if the software is to have any longevity and you have a choice between investing in modellers who swear by code generation tools, or good developers who have the skill and knowledge to create good applications, for the sake of the user, back the latter.