Responding to Dave Orchard's Take on MDA

Dave Orchard had some thoughts about MDA, and I commented on his blog entry very briefly. I’ll try to address each of his claims in more detail below. I have elaborated many of the points in an older posting; it might be a good idea to read it if you’re looking for some initial discussion.

Dave says:

The first lesson to learn for MDA is that “abstractions”, like a logical model, typically worsen performance and there is a need for selectively optimizing performance.

First of all, I think a logical model is something that you just can’t avoid having — if you design any sort of application, you’ll have a conceptual model of your entities, their relationship, your processes, and so on, regardless of whether you actually draw this as a UML model in some fancy CASE tool, on a napkin, or just keep it all in your mind. You will think of he Customer having n Contracts, and each Contract referring to n Articles, or something like that; it’s highly unlikely that you will think of your application’s concepts in terms of the underlying technology.

The point Dave is trying to make is, if I guess correctly, that having a uniform way for mapping this logical model to a specific implementation strategy worsens performance. That’s true, and it is a common trade-off: Uniformity will make your system easier to understand because things look more or less the same; it will not offer the same performance as the manually tuned solution that can take all of the specifics into account.

While I agree in principle, I believe that in every (complex) application, you will have some guidelines that describe the default “mapping”. In most J2EE applications, for example, you will decide on one general strategy - such as “We will use EJB CMP” or “we’ll use Hibernate” - and stick with it, except for the places where it’s justified to deviate from your own standards.

As you will always have a standard way of doing things, an MDA approach will automate this, saving you time; it will localize the concept in a single place, so that it’s easy to understand; it will increase quality, since you’ll be doing it the same way automatically; and it will allow you to evolve your strategy should you find out that it can be improved.

Dave continues:

We had a bigger problem though: The developers hated it. Somebody would create the logical model, they’d push the “generate” code button, and then run the software. But guess what, they always got the model wrong. Maybe they forgot about the zip code in the address, or the middle name in the name structure. So the model needed to be updated.

So far, I see no problem — you of course don’t get everything right the first time, so you’ll have to update and change your model. I fail to see anything particularly tied to an MDA approach so far. The actual problem seems to be described in the next two sentences:

To make a simple change in the model and then generate took way too long. It could take up to half an hour before the system could be retested. The devs simply would make the change they needed in the place they needed it. For example, the SQL already had the zip code so they only needed to add the zip code in the Java and in the SQL select.

If it takes half an hour to do this, something is wrong with your tool set. There are generators that can generate hundreds of files in under a minute; depending on the CASE tool, the XMI export itself may sometimes take longer than the actual code generation step.

Even more importantly, in my experience the example given (“they only needed to add the zip code in the Java and in the SQL select”) is an argument that clearly shows where the strengths, not the weaknesses of MDA lie: In a real-world architecture, you’ll have to change the zip code in the SQL DDL, in the query string (as well as in the update and create statements); you’ll have to add it in the place where you extract the data; you’ll have to add it to some Java object, create getters and setters; extend some interface (e.g. in one of your EJBs); might have to add it to some FormBean, modify the code that copies it from some back-end object to the front-end object, etc. etc.

Saving time by doing this manually? I don’t think so.

Next quote:

I assert that MDA systems almost invariably suffer from the “design documents collect dust on bookshelves” problem, despite best attempts of the tools and organization to stop the natural entropy

I assert that anytime you use modeling, UML or not, and you don’t use an MDA approach, you will suffer from this problem (since the model just is part of the initial design documentation). With MDA, you make your model part of the development artifacts; it can’t get out of sync (that would be like part of your source code getting out of sync). Of course you have to enforce this, but this is no different than disallowing people from modifying the byte code emitted by javac.

The technology simply introduces an artificial layer of abstraction that is too difficult to modify and build high performance systems.

By the same logic, I could say that EJB CMP introduces a layer that makes it impossible to build high performance systems. Or Java. Or maybe even an RDBMS. After all, not being tied to the relational abstraction will allow me to build a faster system - right?

Stripping down the rest of Dave’s posting, I believe the key statements are

A final problem with MDA systems is that they don’t really solve the hard problem. […] A final problem with MDA systems is that they don’t really solve the hard problem.

I totally agree; anybody who claims that MDA solves all problems, and turns it into a silver bullet, is clearly wrong. I believe that software development is hard; but it’s hard enough to deal with even with an MDA approach. Without, it becomes unnecessarily harder - I see no reason to do this.

Dave’s summary is:

In conclusion, I believe that MDA systems solve a small portion of systems development and will typically suffer from the “stale design” and performance problems. I think the path forward for software development is perhaps to use MDA as a prototyping exercise, but the real productivity gains will come from ever increasing productivity tools (like better GUIs, APIs and programming models) and increasing metadata.

As I hope to have made clear, I strongly disagree with the first part of this statement. Using MDA for prototyping only clearly misses the real benefits — and in my view, MDA is only about increasing productivity, nothing else.

I’m not a fan of statistics, and I don’t particularly believe in specific case studies being generalized to an overall productivity gain. But I know from experience that especially in scenarios where you have a big code base, a strong set of architectural guidelines, and an application that is more data-centric then process-centric, the productivity gains are significant. Especially with EJB/CMP-based backends, the percentage of generated code (for this layer) can be up to 100%.