A critique of Fowler's MDA critique
February 3, 2004
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!
About
This page contains a single entry from Stefan Tilkov's Random Stuff posted on February 3, 2004 6:10 PM. The previous post in this blog was Fowler on MDA. The next post in this blog is REST vs. SOAP (again). Many more can be found on the main index page or by looking through the archives.
Comments
Amen to that. I think the biggest single thing working against MDA at the moment is the perceived lock-in to various OMG standards, in particular UML (1.x or 2, take your pick). For me it is about the much more general concepts underneath, of having models as the primary artifacts of system design, and using these directly to generate systems and to keep then them in sync with the inevitable evolution of both design and deployment details. I’ve been doing MDA for years, albeit only in a research prototyping environment, and have never used UML in anger. Its a shame to see names like Steve Cook and Martin Fowler appearing to throw the conceptual baby out with the marketing bathwater.
Posted by: Jim Steel at February 4, 2004 9:18 AM | link
Overall, Martin Fowler has not done project with MDA. We can talk all we want about UML 1.X to 2.0 and entity bean relationships and what not. The bottom line is that if I can take a design of a system, then generate a large portion of the framework of a J2EE/.Net application, then I go to executive management and say I can reduce your infrastructure cost and make your operations side of the company more strategically aligned with IT, goes a lot further than talking about modeling substring patterns…what’s the business value of that!!! Get a clue….MDA is the 2nd iteration of CASE tools. MDA is what case tools should of been…modeling the business and decoupling it from the architecture is a way of preserving the business. Its not about IT….It’s about business!
Posted by: Stan Sewall at February 4, 2004 10:23 PM | link
I agree; one method I have found to be convincing is to draw all of the systems elements on a whiteboard, and then color those than can be generated. Especially with architectures such as EJB, this usually makes people aware of how much boilerplate they write.
Posted by: Stefan Tilkov at February 4, 2004 11:34 PM | link
I don’t mind being “locked in” to a standard - that’s the point of having standards.
Martin and Thoughtworks by the way have some level of partnership with Microsoft; he appeared at my company recently in an event arranged by our local Microsoft rep. His credibility to critique MDA is therefore compromised, despite his stature.
Posted by: Charlie Betz at February 7, 2004 4:36 PM | link