Terry Bollinger

Ashburn, Virginia, USA

IT Analyst

A SKEPTIC'S LOOK AT MDA
Terry Bollinger - 2004-04-23
terrybollinger@erols.com

Avatars of Software Design

In web-based virtual worlds, users who have worn out their welcome in a region often can start a new simply by choosing a new avatar that others will not recognize immediately. Humans are by nature more inclined to give the benefit of the doubt to a new image with a new sounding set of claims, until they learn the hard way that it is really the same old package with a bright new wrapper.

Visual programming is a concept that has been around for quite some time, and it too has had multiple avatars over the years. Arguably, Model Driven Architectures (MDA), with its emphasis on creating high-level models from which traditional code is generated, is the latest avatar for visual programming. The danger is that by focusing too much on this new external presentation of visual programming concepts that a number of intransigent and decades-old limitations of this approach may be overlooked.

Visual Programming: The Good

Without doubt, visual programming has value in the right set of circumstances, and the remarkable capabilities of the human visual system make this style of programming a required part of any overall understanding of how humans develop this strange stuff called software. A good example of where visual programming outperforms traditional text programming by orders of magnitude is in the creation of graphical user interfaces through direct manipulation of screen images.

Visual Programming: The Bad

But here is another scenario to consider: You create a general architecture using an MDA tool or one of its older code-generator analogs, and the MDA tool converts that high-level view into a specific framework that makes use of, say, J2EE and Java. So far so good.

Then you notice that you must do a little "extra" coding within the framework to add the details of your specific situation and environment. The MDA framework accommodates this need readily, so the added work doe not seem that odious. You fill out the framework and, in time, are able to release the resulting system to you user community.

Your customers immediately suggest changes, of course. Some of the changes affect your overall model, but most of them affect your direct code additions. If start with the changes that affect the model, you discover that you have disrupted the code you added, since the generated framework is no longer the same. If you start with the code changes first, you lose the benefits of the model viewpoint and still cannot add in the framework level changes. Frustrated, after a couple of weeks of indecision you decide to abandon the MDA tool and framework and switch to direct code maintenance. The decision is effectively irreversible, since once you begin making the needed framework-level changes, there is no longer any practical way (or even a good reason) to make it backwards compatible with the original model and tool. Besides, after working more with the code and changes you have realized that your development team can produce a much more sophisticated and more efficient framework that the very basic, non-customer-specific code generated by the original MDA tool, which of course had no understanding of your customer’s needs.

Visual Programming: The Ugly

You add up the benefits of having used the MDA tool, and find that they were... non-existent, or possibly even negative. While the MDA tool did reduce the amount of coding you needed to do for the very first version of the tool, in retrospect you realize that the resulting design was both overly constraining and inefficient, and so had to be analyzed and then significantly modified by your design team. Even more importantly, the tool proved too painful to use during long-term support of the software - which for your package, as with most software, proved over time to be more costly by a wide margin than originally creating the software. You decide that MD