Jürgen Mutschall ponders what is to be done to make MDSD a mandatory development methodology for every large scale project.
Jürgen Mutschall has been CEO of Distributed Engineering Systems Software GmbH since 1996 and took part in multiple large scale international projects as project manager, architect and consultant. He has designed and developed model driven software tools and visual programming languages for more than 25 years.
Code Generation conference is the leading event on the practical applications of Model-Driven Software Development (MDSD). It offers a high quality learning experience through discussions, debates, a diverse range of practical tutorials and workshops. Now in its 7th year, it is known for providing a high-value learning experience and attracts industry-recognised experts to share their experiences.
The answer is: nothing can make MDD go mainstream
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.
What if the code was the model.
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 :
(start reading at "Model driven architecture is a wonderful idea, a grand idea that has never worked and probably never will.")
Re: The answer is: nothing can make MDD go mainstream
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.
The lady said that she has been doing 100% code generation for 20 years
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.
It will happen!
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.