Why aren’t we all doing Model Driven Development yet?
About a month ago Kees Dijk asked a question on the programmers StackExchange titled “Why aren’t we all doing model driven development yet?“. He reiterates his question also as “What do you see as the biggest problems that make you not even consider model driven development?“. It shouldn’t be a surprise that I’m interested in these kind of questions. The answers, in this and other discussions about this subject, are interesting food for thought. Why? Because if you only read these 15 reasons why you should start doing MDD you would become curious why we aren’t doing it all by now…
Let’s look at some of the main concerns which prevent people to use MDD, as mentioned in this StackExchange thread.
No Silver Bullet
The most upvoted answer on the programmers StackExchange refers to the essay of Fred Brooks “No Silver Bullet – Essence and Accident in Software Engineering”. Written in 1986 and still a valuable read! Brooks follows Aristotle in dividing difficulties in essential and accidental ones. Essential tasks in software engineering are about the fashioning of the complex conceptual structures that compose the abstract software entity. Sounds abstract, but it means that constructing data sets, relationships among data items, algorithms, and invocations of functions is complex, inherent from their representation. Accidental tasks in software engineering are about the representation of these abstract elements in programming languages and the mapping of these onto machine languages within space and speed constraints.
High-level languages are solving some of the accidental difficulties and are therefore valuable, but the essence of the problem remains the same. The specification, design, and testing of conceptual constructs need to be done by people, no tool will help you with that.
Dangers of MDD
Some followers of this blog may think I’m such a hardcore fan of MDD that I will now start defending MDD against Brooks. However, let’s first try to get a balanced view on MDD. Please take notice of my previous articles 8 reasons why MDD is dangerous and 8 reasons why Model-Driven approaches (will) fail.
In the first article I point at the following dangers:
- MDD actually introduces a lot of rigidity.
- Models are only flexible where flexibility has been designed.
- The roles of project members are quite different.
- The modeling environment doesn’t always support version control.
- The modeling tool / approach is “almost” finished at project start.
- The requirements team needs to understand what is allowed and what not.
- MDD is sold to the customer, but the team has no experience.
- Innovation distracts.
In the second article I mention the following eight reasons for possible MDE / MDD failure:
- Not targeting all goals of Model-Driven Engineering.
- Only using one modeling dimension: the dichotomy between PIM and PSM.
- Focusing on generating new artifacts.
- Using general purpose languages.
- Using custom defined domain specific languages.
- Using model transformations which are not fully executable.
- Not testing the model.
- Insufficient tooling.
I’m mentioning these items for two reasons. First, not every approach called MDD is the same. Hence, your experience with MDD cannot be extrapolated to MDD in general. Second, MDD is indeed no silver bullet. You still need to think about the complexity of your domain and the approach you want to use. There is a lot of difference among MDD approaches and you still need to select the right approach for your situation.
Tool support and popularity
An interesting answer on the question comes from “mko”: “Microsoft / Apple / Google isn’t pushing it“. He adds “What kind of development gets popularized has much to do with tools, backer and evangelism“. How true this is was shown in 2008 when Bill Gates introduced the Oslo project thereby creating a lot of buzz in the market. However, after it’s sudden (and fast) dead it’s a bit quiet again. Stuart Kent recently explained that Microsoft still has an MDD strategy.
Juha Pekka also points at a popularity problem:
I believe that there are several reasons but one is for sure that MDD is not in the curriculum of universities. Typically the closest is a course that teaches modeling and there the models stay as sketches (no checking, code generation, debugging at model level). This “modeling” course often also introduces UML and students are puzzled why to learn such a large and complex notation when the value of created models is low.
Contrast this to other field of engineering like embedded-hardware developers or control engineers where students get a quite different experience. With tools like Simulink or Labview students can draw a model and then it generated you the code, or at least you can run it in simulation.
In the past universities teached compilers and parsers, but now they should teach how to make generators, implement DSLs, etc.
Some people also point at tool support as an important reason. If you develop software you want tool support for refactoring, debugging, testing, validation, etc. The workflow is also important as code generators often introduce additional steps.
Modeling != Programming?
A more fundamental question is whether we should see modeling and programming as the same thing. Berin Loritsch touches this subject by making these points in his answer:
- Because there are programmers like me who get more progress and results from TDD than MDD.
- Because Modeling != Programming.
- Because a model that sufficiently describes a function to generate the code is no longer useful as a model.
- Because there are programmers like me who only use models at a high level, and then work out the details with code. You see things differently in code than you do in modeling software.
Does MDD need to convince programmers of the usefulness of modeling? Or does MDD lead to changing roles in software development? JetBrains MPS takes another position in providing an environment to seamlessly integrate programming and modeling (e.g. Java and your DSLs).
Are there even reasons to think about MDD?
Why should we even think about using MDD? I mentioned some reasons to start using MDD before. See also a previous article about successful applications of MDD in practice. Don’t limit yourself in thinking that MDD means UML + code generation. Notable success stories often involve engines interpreting models like business rule engines, business process / BPEL engines, or (not to forget š Mendix. In my experience most of the problems mentioned before about tool support are solved nowadays.
But, let’s get back to Fred Brooks. He stated a fundamental difference between essential and accidental complexity. As an example of accidental complexity he mentions high-level languages and explains why they don’t give us the big leap in productivity we want. It can solve most of the accidental complexity, and I think MDD actually does so, but we need to address the essential parts of software development. Brooks gives four suggestions addressing the essential complexity when he gives an abstract of his 1986 article in 1995 [1]:
- Exploiting the mass market to avoid constructing what can be bought.
- Using rapid prototyping as part of a planned iteration in establishing software requirements.
- Growing software organically, adding more and more function to systems as they are run, used, and tested.
- Identifying and developing the great conceptual designers of the rising generation.
In my opinion MDD actually addresses the suggestions in the “No Silver Bullet”-article. First, it removes most of the accidental difficulties and let’s you focus on the essence of the design. Second, it enables rapid prototyping and if you use it as part of an Agile Application Lifecycle Management approach you also have a great way to organically grow your software.
A relevant question?
This post mainly contains questions. It’s not my goal, this time, to answer them… I recently gave my opinion about the future for Model-Driven Development. Do you think questions about the usefulness of MDD are relevant? Is there a future for Model-Driven Development? If so, how can we make MDD live up to its promises? How to address the “problems” of MDD mentioned above?
Please share your thoughts in the comments and consider joining my fishbowl discussion “Making Model-Driven Software Development live up to its promises” at Code Generation 2011!
————————————–
[1] Frederick P. Brooks. The Mythical Man-Month, Anniversary edition with 4 new chapters, Addison Wesley (1995)
Photo by alshepmcr
15 Comments Added
Join DiscussionThere is not enough consensus on what model-driven development really is about, little between the people promoting it, even less so from detractors and the general target audience(s).
I guess until any players manage to cross the chasm, MDD will continue to be a fuzzy term. When that happens, their vision may define with more precision what MDD actually is. Or maybe they will choose to call their approach something else, to distant themselves from the fuzziness altogether.
On Juha Pekka’s statement:
1. Totally agree that Embedded and Business software development are very different in the level of rigour of modelling.
2. Think, models on a sketchy level are quite common, not only in education. It’s the level on which most of business sw projects are (still/ already?) operating these days.
Define ‘we’.
‘I’ am using MDD.
Software Factories FTW!!!!
I am using MDD in my startup, to generate a family of information systems, ie. I have a model driven product line.
Now, there are definitely purists in MDE that consider my approach is a MD-hybrid at most, due to the quite heavy model-to-text phase. Yet I don’t see a different effective and maintainable way of creating crud web apps in a different way, and am very happy with how things work out in practice.
So to get to my point, when is someone actually doing MDD, ie, what is it, and what is it not? I’m not sure there is a clear view on this, a bit like the web 2.0 buzz word.
Anyway, I love it, especially now there is a nice set of tools to manipulate models, generate code from models, and MDD is a great way to create DSLs.
I still wonder if and how MDD is feasible in creating one-off products, but for reuse I think its great.
Hi Rafael,
>I guess until any players manage to cross the chasm, MDD will continue to be a fuzzy term. When that happens, their vision may define with more precision what MDD actually is. Or maybe they will choose to call their approach something else, to distant themselves from the fuzziness altogether.
Good point. I think in most cases they won’t call it MDD unless they sell developer productivity tools. Maybe not to distant themselves from the fuzziness, but at least to define their product in customer value instead of the technical enabler (which MDD is in such cases).
Hi Marten,
Thanks for sharing your experience. I’m not an MDE purist, so no problems with your approach š You should apply these techniques in the way they suits you the best.
I think reuse indeed is a strong case for MDD as it is probably easier to reuse (and customize) high(er) level models than code (in a traditional programming language).
One thing that is great on the reuse aspect, is that reusing a module (in ‘normal’ programming) is one thing, but hooking it up, that is, integrating it, into a system is another. It almost always requires some initialization code, or dependency injection code, or some other glue code.
MDE can really be beneficial here, if you have a good architecture. In my Product-line, I use some pretty pragmatic ways of generating this code, since most information is already available in the models (like relations between classes in a class diagram for instance, and depending on the abstraction level, there can be more technical info available like MVC pattern info, or whatever).
And also, I can say that MDD can provide a proper foundation, when used as a framework for generating ‘default’ behaviour from models. Twere are then various ways to tweak this default behaviour into custom behaviour. I use feature models and annotation models on the highest level of abstraction, but also there can be really nitty gritty details that should be changed, and then I use things like normal inheritance.
I used MDD for embedded development. Specifically, Cisco UCS (the blade server platform) management and control plane. I had to write my own tool-chain and framework. The underlying need was chiefly, like in most management and control apps, to reduce amount of repetitive cut-and-paste like coding, and desire for overall consistency. This was not the first embedded MDD-based system I built.. That said, I could not find any suitable framework that would satisfy what I wanted to build..
According my experience MDD doesn’t help you to reduce paste-copy and other bad things in your code if your developer doesn’t know about the good design. š I took a part it in two big MDA-based projects by my customers. The code was terrible. I think that you can better reduce past-copy and write your code effective with the high quality using the design patterns.
Yauheni
Well, yeah.
I am generating code using, in the last step of my MDA, XPand, and the code in these templates uses design patterns.
But it’s really a good idea to search the right technology: What model-to-model language, what model-to-text language, what kind of meta models are we going to use, how to do feature selection and integration, and THEN:
The eventual language of the code that rolls out, what quality properties can it provide? I am generating GWT (Google Web Toolkit) code eventually, with the widget/server library of SmartGwt.com on top.
The amount of MVC and server-side facade crap (the amount of server-side code in general), is HUGELY reduced, due to the server framework of SmartGWT. If I picked normal jsp technology or Spring or something, I still would have a very large server side code base, which I despise. So then, despite using MDA, i’d still have a less preferable solutoin.
SmartGWT basically allows the developer to only code the
GUI’s, taking care of any persistence, (independent of the fact that you use it in an MDA context, or if you just are a ‘vanilla’ programmer using the SmartGWT framework)
So independent of what MDA structure you have, choosing a good target language is more than half the job. I think the good thing about MDD is that you can make a selection of ‘right tools for the job’, and ‘connect’ those to eachother.
@Yauheni: it all depends on what you do and how. Building a model based framework that is efficient and maintainable is not easy. There are applications, s.a. Systems, Network Management systems where using patterns wil not reduce the amount of code and cutnpaste.
It’s interesting to see that this question has become a hot topic recently, Jean-Jacques Dubray has posted a very similar question on InfoQ too.
I think the idea of domain specific languages is not really new (the first conference on DSLs was actually in 1997). The concept of code generation goes back to end of sixties, I’ve recently made some Ngramm Views on this: “Charting Trends on Model Driven Software Engineering”:http://www.hitchhikersguidetomdse.com/2011/04/charting-trends-on-model-driven.html
On the other hand, tool support for the design and realization of DSLs was quite limited to world of compiler construction tools until recently. I believe that the appearance of language workbenches and tools that support meta-modeling gave quite some boost to the development of DSLs.
Without the help of effective DSL engineering tools, the initial effort required for developing a simple DSL would be substantial higher and simply outweigh the benefits of having a DSL, for example, over a library. I think supporting the reuse of DSLs in workbenches – by different types of composition techniques such as extension, weaving, etc. – helps in preserving domain knowledge in a higher abstraction level in the form of languages, instead of libraries. Secondary tool support, for example, for the comparison and merging of models, or for the co-evolution of meta-models and models has also positive influence on taking the steps towards adopting DSLs.
On the other hand, DSLs can still not be used as freely / conveniently as general purpose programming languages. Consider, for instance, the convenience of advanced debugging facilities, or the portability of Java, or the flexibility of dynamic languages. So the tools still need to be improved so that domain experts can use the domain specific modeling environments (both graphical and textual ones) as programmers can use the standard programming environments today. In addition, the engineering of DSLs requires specialized knowledge that is often not available in every organization and in general, not well-established in the state of the software engineering practice yet. I agree with Jukka Peha that MDD is not part of the curriculum in most of the universities still. Eindhoven University of Technology and Delft University of Technology are rather exceptional form this point of view with their master courses on model-driven software engineering.
So there is still a lot to do before model-driven software engineering can become a widely accepted technology.
Istvan, excellent comment. I completely agree with you.
Allthough, when rasing the level of abstraction or moving more to declarative code, debuggers are less ‘needed’.
I think the metamodel concept is a great way to tie alot of technologies, language workbenches, etc. together. If they all share a common meta meta model, like ECore for example, integrating things becomes more and more feasible.
By the way: you should mention the University of Twente also, the other Dutch uni that has MDD as a master’s course. I managed to graduate there recently on the subject. š
We can not even get most programmers to switch to Smalltalk, which is not rigid, provides most of the advantages claimed for MDD, has excellent tool support and doesn’t need organizational changes.
I think Rhapsody from IBM is a very good tool to design embedded system appplications.