What's Needed to Make 'Model-Driven' Mainstream?

I've been in this business a long time and I once believed in the promise of MDD/MDA. However, experience in a wide variety of contexts has taught me that the best way to generate code... is to write code. Nothing is as concise, expressive, evolvable, productive, and usable in rapidly-evolving industries as plain-text source code (at least when written in a "good" language). I've seen very few MDD approaches, visual or otherwise, and other attempts to replace source code come close to what's possible with coding itself. There have been special-case successes, such as LabView for instrumentation. For the general case, I wonder where Google would be today if MDD were the mandated approach internally?

Another fundamental flaw is the over-emphasis on domain modeling. Perhaps the biggest failure of OOSD/OOP, at least the way it is actually practiced, is the unquestioned assumption that building a model of the domain in code is a GOOD THING. In fact, it has created the bloatware we find everywhere. Of course, we need to understand the domain in order to build software that meets its needs. However, that software needs to be a minimally-sufficient calculation of the data the domain needs, not be a model of the domain itself. MDD only exacerbates this misdirected focus on realizing the domain in software.

In part, MDD is too grand in its scope. Far more successful are focused APIs that encapsulate boilerplate in particular scenarios. For example, well-written code DSLs (domain-specific languages) are highly successful. If that's what people really mean by MDD these days, then great, but this presentation appears to be making the old, and in my view obsolete, arguments.

Someone left just after the presenter said "Every manual written line of code is bad!", and it sounds like he almost fell out off his chair (15m35).

I think the actual model/design is the code, and the compiler the blue-collar worker that translates it into the binary executable product (cf. Jack W. Reeves essay, 1992).
The code is the only formal description of what the software does (discarding compiler optimizations).
The model (as presented here) is just a simplified overview of it, useful for introduction to the code, or some big-picture and superficial considerations (especially the "boxes and arrows" part). It should rather be generated from the code (which happens in practice), than the opposite, for you can't automatically generate precisions and details that require further business and technical considerations and tradeoffs.

That said, I would welcome the appearance of higher level languages in which you could elegantly express and represent nearly all desirable features, and which would then execute nearly as efficiently as possible, but to me modeling as described here doesn't seem to go one inch into that direction.

Agree with D. Wampler about code DSLs.

B. Russel said : "Everything is vague to a degree you do not realize till you have tried to make it precise." This applies very well to MD*.

PS: A link to an interview of R. C. Martin where he talks about MDA :
blog.xebia.fr/2011/05/25/interview-avec-robert-...
(start reading at "Model driven architecture is a wonderful idea, a grand idea that has never worked and probably never will.")

I was once sold on MDD as well and wrote several thousand lines of java code to transform UML models of business-to-business collaboration to BPEL and WSDL artifacts. I don't want to go through that experience again (plus its painful to do anything complex in java).


Modern IDEs and tooling that offer domain-specific code generation (for service interfaces, RDBMS, etc.) are still useful as long as one can easily mix generated and hand-crafted code (e.g. partial classes in .Net).

More recently I have found that functional programming languages are MUCH better than OO languages for building DSLs. Languages that support metaprogramming well are really quite ideal for building DSLs.

I am mostly experienced in F# which offers all of the DSL crafting facilities mentioned plus the innovation of TypeProviders. With TypeProviders, the IDE, compiler and language features work together to present external metadata as ordinary language types - at coding time!

Just yesterday I came across a very interesting paper on type providers in Idris - a Haskell-like language which supports dependent types (itu.dk/people/drc/pubs/dependent-type-providers...).

I will summarize by saying that much of the original need for MDD is being met by better languages; innovative new language features; and better IDEs/tooling.

How about show us how she does it?

PS: At this point, I think code generation is the wrong way to do model driven development. The model should execute itself for MDD to work, it shouldn't be generating code. But what the model can't represent you should be able to write some code for it. The question is what tools are out there that allows you to execute models instead of code? Also I don't think any of the modelling notation is descriptive enough to execute and if they do become descriptive enough, they will probably be way too complicated.

Thanks Infoq for delivering such interesting content.

This reminds me of how many physicists were more excited at the prospect of not finding the Higgs. Because I think the "right" tool does not exist yet. I do believe there are benefits to be gained in using existing tools. But for many reasons they are not for everyone, so the potential is still there.