Comment Form without the JavaScript Editor


DSM

Code Generation 2011 -- fulfilling the promise of MDD

May 06, 2011 12:22:44 +0300 (EEST)

Code Generation 2011 is coming up fast: less than 3 weeks now! If you haven't already got your ticket, book now -- as I write, there's one discounted ticket left. As in previous years, the lineup is impressive: Ed Merks, Terence Parr, Jos Warmer, Johan den Haan, Pedro Molina and of course experts from MetaCase, Itemis, and Microsoft. It's great to see 10 out of 27 sessions are Experience Reports or Case Studies: Model-Driven Development is an industrial reality, and the media attention comes from real world successes, not academic theory or vendor hype.

Still, MDD has a long way to go to fulfill all its promise, and there are many misunderstandings and prejudices to be corrected. Often the best way for people to learn more is through a discussion, so I was pleased to see Johan den Haan's Goldfish Bowl on "Making Model-Driven Software Development live up to its promises" -- and happy to accept his invitation to kick things off on the topic of "To make MDD successful we need to focus on domain experts and really abstract away from code". Other suggested recipes for MDD's world domination include "marketing", "alignment with programming", and "better education".

Looks like there’s an interesting three-way divide on these MDD issues, depending on the kind of language and who supplies it:

  • vendor-supplied general purpose language (e.g. Rational Rose)
  • vendor-supplied domain-specific language (e.g. Mendix)
  • customer-created domain-specific language (e.g.with MetaEdit+)

The first two are obviously an important distinction but not a black and white one, more of a sliding scale of domain-specificity. And between vendor-supplied and customer-created are variations like vendor-supplied customizable, consultant-supplied etc. (about which more in Juha-Pekka's "Build or Buy" panel at CG2011).

Probably it comes down to three main orthogonal dimensions, domain-specific vs. general purpose, problem domain vs. solution domain, and in-house language ownership vs. outsider-supplied. We could add other dimensions, e.g. text vs. graphics, which is really a sliding scale from “text as characters” through MPS and Visio to “graphical with reusable objects”. Together these dimensions give us a wide and varied space, basically encompassing what gets labelled as MDD. The space is however far from homogenous, and certainly not evenly populated. Instead, there are lots of interesting clusters where the answers to these issues are similar, but radically different from other clusters. In that respect, there's no one recipe for MDD promotion.

For me, there’s no one recipe for MDD practice either: it depends on the focus, scope and size of the project, the abilities of the developers, and the availability of tools. But I’m pretty sure industry behavior as a whole is inefficient in having too generic languages, too much focus on the solution domain, not enough in-house language building, and too much in-house tool building. So I’m happy to preach the good news of companies creating their own problem-domain specific modeling languages with a good language workbench!