A critique of Fowler's MDA critique

I promised to follow up with some more thoughts on Fowler’s posting, so here we go …

First of all, I really like Martin’s work - I’m a long time admirer of his books and own about three of them. In this particular case, though, I believe that he is wrong. That would be OK if he were some unknown guy nobody cares about (like me ;-)), but because he is not, and because our industry as a whole tends to attach guru status to people and believe everything they utter once they have it, I believe that he is actually causing harm.

I am a strong proponent of what I call Pragmatic MDA. Pragmatic, because I don’t believe any technology can be a silver bullet, and not every thing that is mentioned in the context of the current MDA hype is worth the paper it’s written on (or the bits it’s encoded in. But I digress.) So let me state some of my own beliefs about Pragmatic MDA up front:

• Pragmatic MDA is not about expressing everything in the model, and most definitely not in graphical notation. I don’t believe in executable UML unless it’s applied to very restricted domains, such as embedded systems (and I state this only because I know next to nothing about that domain).
• A tool that generates code according to some internal, unmodifiable, hidden set of rules, is not an MDA tool. To me, the ability to modify every aspect of model and/or code generation is essential for the approach to make sense.
• Being a proponent of MDA does not mean that one considers UML, especially 2.0, or XMI to be great. In fact, I totally agree that they have their own set of problems.

MDA, in my book, is about providing the developer with a tool set that enables him (or her) to build and modify the system in a way that’s a lot easier than the traditional approach. Instead of spreading knowledge about design patterns, programming language idioms and platform details across a multitude of different artifacts, where they are mixed with domain/business knowledge, this technical knowledge is localized in code generation rules. This works to a certain degree, not perfectly; it still beats the approach to code everything by hand by a very significant percentage.

Let me address some of Martin’s criticisms in more detail.

• First of all, Martin gives the example of activity diagrams that are, in his opinion, not better than writing code in a modern language. That’s absolutely true! It’s also absolutely irrelevant. If something is more efficient to do in a programming language, by all means use that. That does not mean that everything is easier to write in code; if it were, nobody would have come up with the MDA idea in the first place. (As an aside, our own tool, iQgen, supports code generation from activity diagrams. And guess what? We have never used this feature (although we plan investigate whether it might be appropriate e.g. for generating a Struts configuration file).) This is clearly a side-effect of some silver-bullet promises that have been made about UML and MDA, which backfire now.
• If there were a modeling standard that focused not so heavily on graphical notations, were simpler, and as accepted as UML, I would happily advocate that. Sadly, there is none; and while coming up with your own XML language for marking up software structure is pretty easy, there would be no tools to support it. So UML, while not that great, is very clearly the dominating standard. If the alternative is having to write boiler-plate code by hand again, I’ll opt for UML anytime.
• Martin criticizes the platform independence, and he is right in doubting the .NET/Java platform claim made by the OMG. Again - I agree. But he misses the point again; in our projects, a platform is not lower-level than .NET or Java, but higher-level. For example, your platform might in one project be AIX/Weblogic/Entity Beans/Session Beans/Struts/JSP, and Solaris/Jboss/Hibernate/Session Beans/Systinet WASP/Tapestry in another. (And in both scenarios, you are likely to have built your own framework layer on top.) In these scenarios, it’ actually pretty easy to hide a lot, if not everything, of those platform decisions from your model.
• Generating code, some say, is a code smell, and to a certain degree, this is true. But it’s sad fact of life that most mission-critical systems - which are those my company focuses on - are composed to large degree of boring, repetitive, monkey-level code. I have yet to see a mainstream application that does this differently. Using the MDA approach to automate this is not something to be done instead of using frameworks, it’s something to be done in addition. The parts of the system that are generated are not source code anymore; the source code is the model + the code generation templates. (In fact, there is some similarity to the macro approach in languages such as Lisp or Scheme. I’ll accept criticism from Lisp hackers any day - yes, we are re-inventing things. Such is life.)
• Pictures are not better than text - at least not generally. But MDA is not about pictures, it’s about expressing structural (and sometimes behavioral) information in a standardized way.
• Martin’s final point about model driven tools that don’t use MDA standards is well taken. In fact, I have argued for alternative, more programmer-oriented input formats in the past. Still, the MDA standard are what is currently available, and I much prefer a less-than-perfect standard to none at all.

Comments and feedback are very welcome!