This Dilbert strip is a perfect example of a cool technology: everybody feels the need to use it. Your colleagues are using it, clients force you to use it so you end up changing the way you develop software to integrate it even if have no idea why you’re doing it. It’s just that the technology is so cool that you embrace it. Whether the technology actually brings any clear benefit nobody cares. Being cool is enough!
New programming languages are cool. Agile is cool. Cloud is cool. MDE / modeling is clearly not cool. Every time I mention the word model I get the immediate question: where is the proof that MDE improves productivity / quality /… ty. Instead, if I talk about the latest programming language (new Agile method, new cloud platform,…) everybody gets excited and nobody asks if somebody has done any research on whether the new language is better than existing ones. They always give it at least the benefit of the doubt.
I wonder why this is not the case with MDE. Maybe the memories of the UML fever still hurt. Maybe there is something intrinsic in MDE that repels people. Maybe we should stop doing research on new MDE technologies and instead try to understand how we could change people’s perception and make MDE cool. That would probably the biggest advancement in the field of the last 10 years!
Two last things:
- We do have some proof about the benefits of modeling (see an example) but this is not the topic of this post
- I’m not saying that cool technologies do not bring any benefit (nor that right now we don’t have proof of that). I’m highlighting they were massively adopted before that proof existed.
FNR Pearl Chair. Head of the Software Engineering RDI Unit at LIST. Affiliate Professor at University of Luxembourg. Â More about me.
One of the reasons that MDE is not cool is precisely that it has an uncool history (in the form of MDA, UML, 4GL, CASE tools, etc.), and of course, everyone remembers the (perceived) failures before the successes because those get to be perceived as a “logical outcome” of the maturity/fitness/greatness of the tech.
So, maybe we should come up with an entirely new name? 😀
The comparison with Agile is a good one since Agile is much more pervasive (even in a minimalistic adoptation) to a project than MDE has to be. I’m quite in favor of using “MDE in the small” (or “in the trenches”; see http://dslmeinte.wordpress.com/2012/10/01/in-the-trenches-mdsd-as-guerilla-warfare/) in the sense that it’s “just another tech we use in the project” instead of a top-down, completely pervasive paradigm.
I agree with Meinte about changing the name because the other option is just to hide MDE technology inside our products.
I think that one of the main problems we are facing is to convince developers with a strong background in programming languages who see MDE as an opponent. They like hardcoding whereas MDE proposes almost removing such activity from the equation!
In my opinion, it could be more a moral/social problem than a technical one.
There are many developers out there, so it’s hard to come with an explanation that covers all of them, but here an attempt:
I wouldn’t say programmers are against model-driven development. If you take away those that have been disappointed by immature modelling tools, have been let down by the CASE promisses, or equate modelling with big-design-up-front, you end up with programmers that are just indifferent. But while the effect of indifferent is practically the same as of being against, the cure is another, more about that in the end.
By the way: model-driven is not the only technique that has this challenge. It is the same with formal methods. It’s also similar to recommending simple formal technicques, like for example state machines to programmers (no matter if in models or in code). See the following post from Alan Skorkin: http://java.dzone.com/articles/why-developers-never-use-state
The company I am working at (http://bitreactive.com), offers a tool to develop M2M applications, using UML in a smart combination with Java. We observe that most programmers really do not care if a tool means modelling or if it uses UML or whatever standard, as long as it does the job effectively, and the tool is excellent. Another example are Apache Thrift or Google Protocol Buffers: These are used by programmers on a daily basis, and these are effectively model-driven, to some extend. Both have abstract input models (in form of simple languages), and use code generators to generate code that is boring to write manually. The benefit is clear to the users in these cases; no one cares if model-driven principles are used or not.
Why it seems everybody is convinced about agile methods? My guess is that there are some very talented and charismatic *practitioners* that get the “Why Agile” out to the developers. Also, agile methods clearly do not attempt to replace coding. In contrast, model-driven often comes from academia, to which programmers are more sceptical when it comes to recommending new practices. Some programers may simply be scared since some advocates of model-driven techniques give the expression that model-driven automatically implies not to code.
My suggestion: First, tune down the focus on the model-driven principles. When talking to practitioners, focus on *why* a specific tool, technique or technology is cool, not the rather abstract principle “model-driven.” Second, explain how they can apply the expertise that they already have easier. That works against indifference and makes programmers happy.
What about “simplecting” as an alternative/new name?
Mmm, Jordi, I will add my five cents, maybe it is that MetaModelling (MDE) is pretty complex intrinsically (per se). Maybe if we can change its name but also simplify the “thing” we can get that mass adoption we are looking for 🙂
Ideas development process: The art of transforming concepts in software artifacts 🙂 But name it is not understanding how we can make the SysML or UML draws (meta-models) easier for the common programmer (people)
Regards, Nacho.
From a leader of a leader company, the statement that “the industry has its own drivers” as response to the question: “why -the big vendor- promotes MDE in scholastic arenas, but resorts to man-hours artisanal construction?”
— in short: MDE bay be low-risk/high return, but reduces the number of man-hours billed, what is what moves (or used to move) the IT industry budgets.
I’m going to have to disagree with Frank. MDE is not cool with programmers precisely because they want to spend their time coding. With MDE, you spend most of your time modeling and not coding.
As a programmer, I think MDE is cool because you do spend time meta-programming which I find to be very geeky and intellectually challenging in a oddly relaxing way. Most programmers aren’t into that at all. They are quite uncomfortable with modeling because they think it is for wannabees and posers who want to pretend that they can code but really cannot.
@Antonio: …or as one of my former sales managers put it: “Go away! (You’re a threat to my number of billable hours sold.)”. This should be an argument to sell MD projects directly to the business. Usually, IT departments are inhibitors because they don’t want to be proven inefficient. Managers of all kinds are inhibitors because they don’t know and therefore trust the tech.
@Glenn: Agreed, it’s quite a hard separation. But there’s something to take away from that: make modeling look and feel like coding to be able to get to programmers. This typically means: textual modeling languages instead of graphical ones.
Really good question.
But I have given up asking why. It used to be my best friend, out of the 7 wise men of who and what and when,,, etc
But it was sending me crazy – why do developers keep doing it the dumb way even when they see a smart way?
Apple did not used to be cool. To develop the hardware and software was seen as too much – Microsoft developed software and left the hardware to others – they we seen as smart and cool.
Now Apple is the coolest on the plant and everyone is copying them. http://www.bbc.co.uk/news/technology-20072497
So maybe the market has to come to modelling?
And this, I think, is an example of why the market is taking so long – it requires a new mental model (unlike, say, cloud).
http://forum.springsource.org/showthread.php?132308-Why-I-love-Roo-more-than-anyone-else
My two cents for the name’s theory. A simple example of this situation came to my mind the other day while watching TV.
I saw the ad of a service provider to create corporative Web sites in a moment. This type of companies are proliferating nowadays. I’d rather say they are a kind of domain-specific CMSs whose target is SMEs’ Web sites. Anyway, the point is that the slogan was “It’s cloud” …
You see?? Cloud is cool. Non-IT people have even a general idea of what cloud is and if you ask them they’ll probably tell you it’s good for them to have the Web site of their garage, hairdresser or whatever kind of business they run in the CLOUD.
Do you think that many non-IT people have an idea of what MDE is? Probably it has to be our fault as MDE practitioners ’cause MDE is not much more complex than cloud. For instance, think of MDSD in a (extremely) simplistic way: Would you say that people won’t understand the idea of producing software automatically?? Doesn’t seem to be much complex than the idea behind the cloud …
I look forward to see a TV ad finishing with … “It’s MDE” 🙂
Two themes in the replies stand out to me. The tools need to improve, and modeling isn’t coding. The fallacy of the latter provides proof for the former. As long as the models aren’t viewed as the end product, ala. code, then the models will be viewed as (unnecessary) documentation. The tools need to make the transformation of model to machine code as transparent as 3GL compilers, and the editing of models should be as helpful as modern text editors. Of course, the fact that developers have re-accepted the pain of markup languages might refute this argument.
I think that industry is doing lots of modeling: code generators, domain specific languages, query languages, markup languages, sophisticated configuration files, and attribute processors are being used all over the place. It is true that many of the big high-profile modeling tools, many of which are tied to UML and tend to focus on graphical presentation, have not seen pervasive adoption. The problem is that they don’t *solve any specific actual problem*. Instead, they tend to be meta-tools, which you can use to create the solution to an actual problem. Modeling will be cool, I think. We just have to do it right 🙂
Will
Is it possible to minimize the semantic gap between models and code to make this technology more practical?
Just use something let’s call it “executable models”, can it be packaged right into the runtime system and interpreted in the application doing real work?
For example, in some hypothetical system, I would want to mix C source code, data flow diagrams, and asynchronous finite automatas, and compile them into the microcontroller firmware. Widely hyped MDE approach tends to be too much high-level, in the result, there are no (?) tiny usable OpenSource tools let me do some development a bit higher than embedded C still not loosing connect with reality.
There are indeed many approaches for Executable Modeling.
Take a look at https://modeling-languages.com/executable-uml/ and https://modeling-languages.com/executable-uml-tutorial-4-class-logic-modeling/
and see if that is something you could use