8 reasons why Model-Driven Development is dangerous
Last week I gave a talk at the Hogeschool Arnhem Nijmegen as part of the conference "Information Systems the Next Generation". This article is inspired by a talk titled "Model Based Development – How to organize and architect survival of MD*" by Wiebe Wiersema given at the same conference. It was a well-balanced, realistic talk about the do’s and don’ts of Model Driven Development.
While Model-Driven Development (MDD) is getting more and more attention by both tool vendors and developers, I think it’s time to look at 8 reasons why MDD is dangerous. If you recognize one of these points from your practical experiences or if you think you have a solution for (almost) all points, please let me know it in the comments! Although model-driven approaches can differ a lot, I think these 8 points can be applied to almost all of them.
1. MDD actually introduces a lot of rigidity
If you’re used to programming everything by hand, MDD can be quite rigid. The goal of MDD is to ‘program’ on a higher level of abstraction. This means that you have to specify less and generate more. However, this also means that you can’t change every little detail you want. It is, for example, often the case that generated graphical user interface are inflexible and they all look like each other.
2. Models are only flexible where flexibility has been designed
The problem with using models to directly drive the engineering of software is that they are far from flexible. First, you are limited by the kind of Model Driven Engineering tool you use. Second, you’re only flexible in the parts of the solution covered by the used Domain-Specific Languages. The higher level the DSL the more commonalities are ‘hard-coded’ in the framework or engine you use. Third, sometimes models are made flexible at predefined points by lower level expressions or languages. That’s nice, but hopefully it is exactly done at the points you’ll need it.
3. The roles of project members are quite different
You need to be aware of the fact that the roles in Model-Driven Engineering are different from the roles in traditional development. The real technical or programming part is mostly moved to the ‘meta-team’ building the model-driven software factory. Building the solution is done by so-called business engineers instead of programmers. These people need to understand the business (like e.g. traditional functional designers) but they also need to express the knowledge they gather in a formal model. People able to do both these things are quite rare.
4. The modeling environment doesn’t always support version control
If you have experience with building (enterprise) software applications I guess you’re using a version control system. If not you should go and read this nice explanation. Existing version control systems work very well for textual programming languages. However, versioning of graphical models is a far less researched field. Most existing modeling and model-driven tools don’t include a full featured versioning system. That’s a pain when working with large teams.
5. The modeling tool/approach is "almost" finished at project start
The famous word "almost" is pitifully used a lot when talking about how far the model-driven software factory is finished at the start of a project. People building a model-driven software factory using DSL tools will have a lot of fun during the process. However, if the factory isn’t finished and tested in practice before you are going to start a big project you will have a huge risk! If you’re not scared by this article to use MDD, at least use a proven tool/approach!
6. The requirements team needs to understand what is allowed and what not
In point 1 and 2 I pointed at the rigidity and inflexibility of MDD. This is mostly dangerous from a technical perspective. However, it is even more dangerous when the requirements team, i.e. the people talking with the customer, don’t understand the limitations of the used tool/approach. In the ideal situation, the people talking with the customer directly translate their knowledge in executable models. However, in big projects you often see a separation in two roles. As in traditional development this can lead to a gap. This gap can become a nasty problem if the requirements team doesn’t understand the limitations of the tool/approach. For example, the requirements team reaches a consensus with the customer on a certain part of the graphical user interface (let’s say a form), while it isn’t possible to build that form with the model-driven tool without a lot of custom handiwork.
7. MDD is sold to the customer, but the team has no experience
While MDD is becoming more popular, customers start to ask for model-driven solutions. Actually I think MDD will become a hype (again!) very soon, and as with each hype everybody will start sticking the MDD label on their products. Doing a project in a model-driven way with an inexperienced team can lead to at least two problematic situations. First, the solution will not be build on time and it will not fulfill the customers’ expectations due to most of the issues mentioned in the previous points. Second, big chance the end product isn’t as easy to change as you expect from a solution built using a model-driven approach, due to misuse of the tool, not knowing its limitations, or due to using immature tools.
8. Innovation distracts
Last but not least, MDD is dangerous because innovation distracts. People tend to focus on the new tool they are using with all its cool features. Even more, people will start bragging about the great advantages they have with the new technology, in the end forgetting the projects objectives. Experiments have been done actually showing this behavior of project teams starting to use new innovative tools. The important lesson: don’t forget your project management, your process, and all other things you need beside the tool or technical approach you use!
See also 10 Misperceptions and challenges of Model Driven Development or 8 Reasons Why Model-Driven Approaches (will) Fail for a critical analysis of MDD.
Photo by netwalker.
22 Comments AddedJoin Discussion
I am sorry, but this is so 20 years ago, just look up Information Engineering and the IEF.
Are models less flexible than hand-coding? Of course, but how much is that flexibility worth in added time and cost versus generating code that will still meet the functional requirements of the business? In most cases, not much for most companies.
The solution is to craft your own DSL and customize it for each project if necessary. Rebol is THE language to do just that.
> I am sorry, but this is so 20 years ago, just look up Information Engineering and the IEF.
You’re right. That’s maybe the problem of our industry we tend to have a short memory. It seems that we have to discuss this all over again.
> Are models less flexible than hand-coding? Of course, but how much is that flexibility worth in added time and cost versus generating code that will still meet the functional requirements of the business? In most cases, not much for most companies.
You’re totally right again. I’ve seen lot’s of good examples confirming this. Less flexibility is not necessarily a problem, but the team needs to be aware of the limitations. However, try to convince a big IT department of this 😉
Most failures of MDD are not due to technical reasons, but have more to do with project management and awareness.
Hi reboltutorial (nice name ;),
Your solution can fix point 1 and 2, but what about the other six points?
Most of your arguments don’t seem to be about danger but about pain and fatigue.
Example No2. You get what you design. Well yes, that’s how design often works.
Example No3. Roles might have to change. Dangerous for the people whose roles are being changed, perhaps, but not overall.
Example No6. The requirements team might have to understand stuff. What is dangerous about that?
I note the previous comment about Information Engineering and IEF, in which I was heavily involved. The main “danger” then as now was disappointment, when people had unrealistic expectations of achieving fantastic results without applying any management discipline or common sense.
I’ve been trying to sell MDE to clients for a while, which made me think about MD* risks as well. Currently, in my perspective, there are 3 big risks.
Before I continue with the list, I would like to clarify two things
– We (MDE community) all know by now that we can define custom languages and do all kind of transformations with models. (Due to this, many are certain that MD* has low risk.)
– The future of MD* is multiparadigm/multiaspect (this is in contrast to the current mainstream MDD experiences).
Now, to the list:
1. There are gaps in our knowledge of relationships among different paradigms/aspects. (Humans do manage to solve this problem creatively in code, but tools are not creative.)
If your project happened to land in this "gap" of knowledge then it can severely put the project off-track.
2. Companies that are new to MDE and want to go with MD* do not know themselves explicitly (that is what are my actual development processes, where are bottleneck, what is the cost of these bottlenecks). For example, points 1 & 2 of this article are symptoms of applying an MD* modeling architecture that is not well aligned with the process of the practicing company (know yourself). (BTW, this process must be mature).
3. Level of quality of MD* tools can vary a lot. This variation is so severe that choice of tool can make or break your project, even if risks 1 & 2 from this list are not present. Luckily, tools do improve and this item will play lesser role.
As for solutions, I will just mention one for risk 1 from my list: (software) engineering and MD* community should meet more often with Modeling and Simulation (M&S) community as M&S have a longer experience with multiformalism/aspect approaches. The other two risks are something that interest me a lot. Does anyone have positive experience with them?
>Most of your arguments don’t seem to be about danger but about pain and fatigue.
It depends a bit on your point of view whether you call it danger, pain or fatigue. However, without going into a detailed discussion about these words I will give a short reaction on your comments.
>Example No2. You get what you design. Well yes, that’s how design often works.
Yes, but this time the design is limited by the possibilities given to you by the MDD approach. Normally you can just design anything you want (you’re only limited by the quality of the programmers you have). There are of course solutions for this making MDD tools extensible with lower level programming languages and plugin mechanisms.
>Example No3. Roles might have to change. Dangerous for the people whose roles are being changed, perhaps, but not overall.
If you just jump into MDD with your current project team. It can be dangerous for your project if you don’t have the right people…
>Example No6. The requirements team might have to understand stuff. What is dangerous about that?
What I meant is that it is dangerous for your project if the requirements team doesn’t understand the technical limitations of the tool. It will lead to unsolvable problems. With traditional development just everything can be build. With MDD you offer some flexibility and freedom for speed, quality, and better Business-IT alignment.
Andriy, thanks for sharing your experiences!
I think for point 2 you mention, you should have the right process maturity. You can also hire experts or buy a tool and adopt the associated methodology.
I agree with you on your point 3. Tools are getting better and better. The difficulty will be in selecting the right tool!
Sorry for the name, I am consulting for european Fortune 500, they would hate some of my personal opinions about their IT Management :). I didn’t say much because I’m not english native but I will make some effort this time.
For point 3, I am very aware of this: I am currently Project Manager on an IT Project for a client where I also endorse a role of Lead Business Analyst. In this company, the middle management wants to get rid off the programmers, thinking programming has no more value and they can totally outsource this.
I’m totally against that viewpoint and I guess that they were injected that idea by the IT Medias which are fed by the Tools Vendors (see my own ranting here http://reboltutorial.com/ranting/mda-hype/). Unfortunately you cannot fight these forces long term because offshoring is part of Globalization so you need to anticipate that in the future code will be built by tools. So the programmers will be forced to adapt to these tools or build their own.
I think you should not build one single DSL layer but an “architecture” of DSL layers which would allow some flexibilities. Software Architect instead of building the architecture of one specific application would build the architecture of DSL for a whole application domain, refining it with time following an Agile Process.
I think DSL will be the convergence of all parties because it’s just common sense that with growing complexities, human cannot cope with the finest details. Dotnet CLR is managing Code Complexity today, it will be true at all level including Human Level.
There are problems with tools today because we are at the beginning of the trend, but they will improve with time. Personnaly my choice is Rebol which is more than just a programming language but a DSL tool engine by itself which could be used on top of current MDA or MDD tools to make them more agile.
Excellent list. I like the fact that you are not attacking MDD. You are simply providing a list of tradeoffs that everyone should be aware of when MDD is adopted. Information is power. Thank you for sharing this information.
Thanks for taking the effort to explain your thoughts in detail!
>I think you should not build one single DSL layer but an “architecture” of DSL layers which would allow some flexibilities.
I definitely believe in a multi-DSL approach, with each DSL modeling a different viewpoint on the system. How you organize/classify these DSLs is another subject, e.g. with layers, multiple dimensions, etc. Layers sound a bit rigid to me, but that depend on how you define a layer and how layers interact.
A bit later than the others, but the internet is timeless, so here’s my response to your article.
Although I see the point in most of your remarks, I think calling this ‘the 8 reasons why MDD is dangerous’ a bit to strong. These are risks that can be managed, and some are not even risks, but rather characteristics of MDD – in my opinion. Here’s a short point-by-point overview.
1. MDD actually introduces a lot of rigidity
It does, but that could also be considered a benefit. If you look at MDD in the context of increasing productivity of developers, you’ll find that a lot of inproductivity is caused by changing the nitty gritty details in one of many repeating pieces of code, and/or gold plating. In a more rigid MDD environmnet you cannot do that anymore – and gain a lot of time (and money) from it.
As for user interfaces: I’d be glad if they all looked and behaved the same, that increases the productivity of users because they will understand more easily how to achieve the results they want, and which actions are required to do so. Assuming we did proper human interaction design before creating the code generator of course.
2. Models are only flexible where flexibility has been designed.
Yes, of course. You mention DSL’s already – these should be designed in such a way that they allow only the flexibility required in the domain. If you feel limited in flexibility by the DSL you use, you are either trying to do something you shouldn’t, or your DSL is incomplete. (See remark to your danger #5 as well)
3. The roles of project members are different.
Yes, they are, but is that a danger? I’d sooner call it an effect of the paradigm shift. As for the example you give: I doubt if there are less people capable of understanding the business and translating their findings into a DSL based model than there are programmers who really understand the business and are able to translate that into the correct code. My apologies for that monster of a sentence. 😉
4. The model environment doesn’t always support version control.
True, but as Jos Warmer pointed out already 3 years ago (http://social.msdn.microsoft.com/forums/en-US/vsx/thread/1e5c817f-2900-4f75-9303-25d5e855787c/), what works for a coding file environment can work for a modeling environment as well. Of course there are reasons to change the version control slightly (file formats, graphical diff), but we’ll get there. Being careful in this area can get us quite a way with the tools we have right now.
5. The modeling tool/approach is “almost” finished at the start of the project.
I agree that that is a risk, but for different reasons than the once you put forward. Over the past few years I’ve had many ideas and discussions about the right middle way between traditional development approaches and the, sometimes hyped, agile approach. That middle way applies here as well: if you really want to achieve optimal succes with model driven development, some domain/project specific issues will be taken into account. In that sense, it is a dangerous to think you can have the modeling tool/approach “more than almost finished” at the start of a project. Big Design Up Front, as agilists call it, doesn’t work for DSLs and MDD factories, as they don’t for classical coding. A factory and a DSL must grow along with the project and the product – iteratively and controlled, but it’s an illusion to think they are fully available up front.
6. The requirements team needs to understand what is allowed and what not.
What you write here, I can fully agree to. However, I tend to seek for solutions along the line of point 5.
7. MDD is sold to the customer but the team has no experience.
This is the big mistake of all software engineering companies of the past 3 decades. We think we have to sell our technology instead of our solutions. Why would a customer (except for the customer’s IT department) be interested in MDD? The customer needs the solutions, not the means to get there. Of course, if you are a tool vendor your customers are different, but I don’t ever sell my development methods to customers if they ask for a software soltuion to their problem.
And if you do want to apply MD or whatever other approach for the first time – a workable approach is to offer the project based on estimations for your existing development approach, and apply payment based on time and material. You may not be able to do it as fast and efficient as you would like the first time, but if MDD is really more efficient, you will still be faster than before and save your customer some money.
8. Innovation distracts
That is probably the only real danger in your list of eight, and it is closely related to known anti-patterns such as the Golden Hammer.
Keep blogging about this stuff though – different opinions and discussions based on those lead to the best new insights.
Thanks for your detailed reaction, time is not a problem!
>I think calling this ‘the 8 reasons why MDD is dangerous’ a bit to strong
I agree with that, but sometimes that’s a useful habit for a title 😉
>MDD actually introduces a lot of rigidity –
It does, but that could also be considered a benefit
True, but it should be the ‘right’ rigidity for your particular project.
>True, but as Jos Warmer pointed out already 3 years ago, what works for a coding file environment can work for a modeling environment as well.
I know the work of Jos Warmer (I recently had a couple of interesting discussions with him), he did a great job on textual DSLs with name-based references. In that case versioning can just be done with traditional version control systems. However, using graphical DSLs in combination with a model repository is a bit more difficult in the context of versioning. The problem I point at is not that it is impossible to implement, but more that it isn’t implemented a lot in graphical modeling environments.
>A factory and a DSL must grow along with the project and the product – iteratively and controlled, but it’s an illusion to think they are fully available up front.
…and that’s what I call a risk. Including the DSLs and factory in your project means a lot of additional complexity. Most advantages of using MDD don’t hold if you have to build the factory as part of your project (or your project should be very big). The real advantages of MDD will come if you can reuse your factory across many projects.
I believe in agile approaches, but I think the factory and the project should be two separated ‘projects’. The MDD factory should of course take the feedback coming from project implementations into account, but changing the MDD factory leads to a new version/release of the factory. So, each project feature which leads to a change in your factory will take quite some time before ending up with the end-client.
>different opinions and discussions based on those lead to the best new insights.
That’s exactly the reason for this post, and that’s also why I made my statements a bit stronger at some points (in comparison with my own views) – to start a discussion 😉
your analysis is very interesting and I can relate to all points, with the exception maybe of point 8.
However I’m wondering: are these dangers typical of MDD only or other approaches share them too? And in the latter case, do these other approaches suffer from a difficulty in wide adoption like MDD?
If I replace "MDD" with "reusable application framework" in your article, I find that many points still apply in both the technical area and the team/project organization area. I use "reusable application framework" as a broad term to cover software from off-the shelf tools to in-house reusable artifacts. Anything that is the result of a software factory approach is potentially subject to the 8 dangers.
Having said this, let me bring your attention on a particular type of framework: content management systems. It may be a bit of stretch to call them frameworks, but cms’, with their plugins, configuration and architecture, look like the result of a software factory approach too. Certainly, cms’ are no longer simple website building tools – they are proper software platforms. A team is responsible for the reusable/configurable plugins, another team is responsible for the end application development. There is rigidity and flexibility is possible only where allowed (even in GUI’s). Roles, skills, and project dependencies have to be structured in a certain way to make the project successful.
Certainly cms’, unlike MDD, are very popular and I think they don’t suffer much form dangers 6 and 7, which are related to understanding and perception. So is this an area where MDD can improve? I don’t have an answer myself. My comment originates from the fact that cms enjoy an often disproportionate acceptance/popularity compared to their technical merits, while MDD suffers from lack of acceptance, despite the benefits it can provide.
Content Management Systems can indeed be compared with MDD. Thanks for pointing at that! I think we can learn a lot from CMS, they are indeed very popular. Maybe that’s a good subject for a future blog article 😉
>However I’m wondering: are these dangers typical of MDD only or other approaches share them too? And in the latter case, do these other approaches suffer from a difficulty in wide adoption like MDD?
I think a lot of the points can hold for other technological innovations. It would be nice to try to formulate some lessons based on similar cases in history. Does anyone have a nice example?
Your points are very well taken.
However, I see most of your “dangers” are potential positives. 🙂
Keep up the good work.
2. Models are only flexible where flexibility has been designed
To me, this is a key insight when we created our MDA, dedicated to generating business webapplications. In our MDA, we actually make use of annotation models, which are written by a very simple (created in a matter of 30 minutes with XText) DSL. The DSL is a bit to our models what CSS is to HTML. It adds details about it in a separate model.
It’s purpose was specifically to be extensible and flexible, and I must say it works well. Golden egg? Not sure, but we are a year something into our startup, and I must say it hasn’t let us down so far.
MDD, AutoSAR, OSEK, ISO26260.
i hate them, they cant change the world a lot.
make things complex..
Before begining a big project, how Mendix team develop a Business, Functional and Technical architectures documents. It seems that no framework is suggested by Mendix to help an Architect !!! Thanks.
There is an excellent presentation available from one of our architects that explains how to approach complex application architectures with Mendix. It will appear soon (in the upcoming weeks) on the recap page of our recent Mendix World event: http://www.mendix.com/mendix-world-2014/recap/
Look for the video of the session “Divide and Conquer: Tackling Large Apps with Component-Based Delivery” by Andrej Koelewijn.
[…] 4: Why Model Driven Development is Dangerous […]
A very well-articulated article.
I felt compelled to write about few points:
“This means that you have to specify less and generate more. However, this also means that you can’t change every little detail you want.”
One can argue that “need to change every little detail you want” could stem from:
a. Problem abstraction is not done well
b. Need to interface MBD generated code with something which highly is imperative. And off course this leads to a question: is our boundary on what goes into MBD-ed software (and what goes as hand coded) is well thought out?
2. In general, I empathize with you on limitations posed by “domain specific” tools/languages. Many a times, in real world, we have inter domain things to do.
3. “People able to do both these things are quite rare”: I assume both meaning business logic and programmers view.
As is, is that not the case with classic hand written development?
The fact that “people able to do both things” are needed indicates that eventually one expects lesser gaps in requirements and implementation.
Also, for a good MBD tool, one would expect that “meta-team” to be the development team of the MBD tool.
7. Correct. In fact, such situation eventually gets a bad name for MBD.
8. I see your point. Eventually, folks who long on features in tool eventually become developer of the tool.
May be this helps tool mature in long run!
I think, MBD is more successful in the areas where concepts behind the tool have been in existence even before tool itself. One good example is : usage of simulink and/or RTW in control system design and signal processing.
May be you will also like an article that I came across a couple of years back:
(talks about why OOPS never picked up as opposed to its hype in early 2000s)