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 :
- 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!
 Frederick P. Brooks. The Mythical Man-Month, Anniversary edition with 4 new chapters, Addison Wesley (1995)
Photo by alshepmcr