Model-Driven Development: Where are the Successes?

When applying a model-driven approach, its complexity adds up to the project's own complexity, so we're always making things more difficult that way. The layer of complexity we add when using a MDD approach must be as "thin" as possible.

Most current approaches expect a perfect world where everything can be modeled, forcing developers to adapt themselves to their logic and limitations.

A model-driven approach must not get in the way of the developer!

Existing model-driven approaches were conceived by "top-notch" developers/mathematicians. This lead to the assumption that those who would use such approaches are "top-notch" developers too. And this is precisely what is happening: Current MDD practitioners belong to the "top 1%".

Most of the world's developer population (myself included) are what I call the "average developer mortal": developers who are good at their job without actually being "geniuses". People who do things the right way, but pragmatically. We are the "everyday programmer". MDD approaches and tools fail to address us.

I've been studying the developer productivity problem for a decade now, trying to find ways to be more productive. In the last three years I've reached a solution based on code generation that I think I can call a true pragmatic model-driven approach. I'm trying to bring it to the market in the form of an IDE. The approach is called ABSE (Atom-Based Software Engineering), and tries to be very simple and direct, using techniques we use everyday on our job. I've setup an information website at www.abse.info . The IDE is called AtomWeaver and version 1.0 is just been released (at www.atomweaver.com). Both the approach and the IDE are not much more than prototypes at this stage, and documentation is scarce, but you'll definitively be hearing more about ABSE in the near future.

Big Design Up Front - It doesn't work. We know this. Why reinvent it? As soon as there is any kind of distance between the model and what's actually running (I predict as long a period as 5 minutes) the premise starts to fail.

"As soon as there is any kind of distance between the model and what's actually running (I predict as long a period as 5 minutes) the premise starts to fail"

That will happen unless the model *is* the source. Of course it's easier said than done.

"Big Design Up Front - It doesn't work. We know this"

The chosen modeling approach must be iterative. It must let you work on modeled code and custom code at the same time. It's tricky to support that, I know. ABSE is the only approach I know so far that makes custom code a first-class entity on a model.

Anyway, before starting a project you must sit down and at least think about the overall architecture, main requirements, etc. That's roughly "big design up front" too.

While I'm sympathetic with the goals of MDD and its variants, and hope that people will continue to work on this technology, my past experience makes me very skeptical that MDD will ever work for the majority of projects. At best, it seems to work in only a few very specific cases. Off the cuff, here are my reasons why.

Nothing beats a Turing-complete, textual programming language for expressivity and productivity.

I realized this while working on UML tools at a large, well-known company in that space. Granted, there are more expressive graphical languages than UML, but none are more productive at getting your work done than writing plain-ol' text, except in a few specific, targeted cases (like LabView for instrumentation and simulation). Text is the best way to express the details of computation and it is the details that ultimately matter. This is why we still write software using text and text files, after all these years. (Again, I'm speaking from experience; YMMV.) Of course, there is nothing about MDD that requires a graphical language. I'll come back to that point.

Graphical representations are most useful at visualizing at the architecture level. (Nobody I know uses them anymore at the object/component level.) However, compared to text-oriented tools, graphical tools are harder to implement and to integrate into an environment and development process. Do they justify the effort? Not in my personal experience.

So, why not use a textual language for MDD? Textual modeling language are used for some specific "MDD-like" tasks, like wiring components together, feature assembly, etc. I've heard of some successes in the automotive industry, for example. However, for the general case, there are a few problems that undermine the potential of MDD.

First, the better programming languages today are not only most efficient at implementing the details (components?), but they also support the construction of DSLs (domain specific languages) for raising the abstraction levels. Indeed, I've seen DSLs used for component wiring and other MDD-like tasks. So, do we need a special-purpose MDD tool, either textual or graphical, for this purpose. I don't believe we do.

Second, all the MDD approaches that I know of are based on objects. Unfortunately, objects have proven to be poor at defining reusable component standards. That's a controversial statement, but to prove it, ask yourself why the world's most successful "component" standards, like TCP/IP, HTTP, busses in digital electronics, etc. are not object oriented, while OO-based component standards, like CORBA, proved to be too complex to survive the test of time and to achieve ubiquitous, permanent adoption. (Still not convinced? "Design Rules, Vol. 1: The Power of Modularity" discusses the characteristics of successful modularity standards. Very few OO APIs meet those criteria.)

Finally, I think driving the development process from models is less fruitful than it sounds. It leads to over-engineering of objects, in my experience, instead of focusing on core, extremely simple abstractions and growing features organically from them. These days, I base my designs on functional programming idioms, which have the characteristics of the successful component standards that I mentioned, and build up from there.

@Dean,

OO never passed the architecture revolution of the last 15 years. OO increasingly became a syntax to express all kinds of concept and ultimately disappeared in complete irrelevancy. Except maybe for the UI controls (where it got its first success), OO never matched the semantics of anything else.

We also agree that big dogmatic visual representation don't work.

@Dean, @Rui:
we whole heartedly agree on the textual aspects and the necessity to bring code in the picture. I don't know if you ever looked at the article I wrote on MOP (www.infoq.com/articles/mop). The real value I see for a Model Driven approach is to create a solution model that is both technology and architecture independent. The key is to identify these elements of the solutions that are timeless. As soon as you write them in a particular technology and instantiate them in a particular architecture, you lost a lot of hope of evolving that solution when technologies and architecture change.

@Jean-Jacques,

Thanks for your reply. I'm glad you're thinking about these issues, too. Concerning technology and architecture independence, I confess skepticism. Perhaps it reflects the particular projects I tend to work on, but I rarely find that I need that level of abstraction. One of my personal weaknesses is a tendency towards "premature abstraction". It's easy to believe that abstraction is like cow bell, the more of it you have, the better (www.funnyhub.com/videos/pages/snl-more-cowbell....). But all design choices have consequences as well as benefits. These days, I really like the clarity and simplicity of being concrete about details, unless abstraction is clearly warranted.

Yes, I understand your point, it surely depends on the context and there is a fine line between benefits and the precipice. It is just that often in IT we spend a lot of time defining "stuff" that is fairly timeless and yet, we start from scratch pretty much all the time. MDE/MDD should also target the benefit of normalizing the business logic across solutions (custom built or package customization alike).

Anyways, still lots of work to do, the great news is that I see people become a lot more pragmatic about MDE/MDD and the pretty "post card" is on its way out.

The "top 1%" is something that can be hardly defined. While a "top 10%" Java programmer is clearly better than the rest, those "top 1%" may just have a different background.

OTOH, development can't orient itself to the worst 20-30%.

Fortunately, the most stupid people are those who stop themselves for acquiring new ways of thinking.

@Dean

Except your opinion about OOP, I fully agree.

A model is everything that is suitable as a model. If text is more suitable than graphics, then use text. If graphics is more suitable, then use graphics. If math is more suitable, use math. If colors are more suitable, use colors! Only phantasy should be your limit!

Your model should serve your purpose. From then on, put your full intelligence into your code generator, whether it generates code (or your GUI, DB schema) statically, dynamically, mixed, or in some other way I can't imagine.

Not to be too contrarian ;), but I find that code generation creates more problems than benefits (again, usually). Debugging the generated code is often necessary and difficult to do, for one thing. Give me a language and APIs that let me express what I need to do very succinctly!

If you need mathematical derivations (first and second), or GUI-portable software, you will hardly avoid code generation, especially the dynamic part. Isn't Hibernate a kind of code generator too? As is garbage collection?

It's true: Each component, that you introduce, must be tested and debugged. However, if the other 90% loose their complexity, then it's worth.

At least, MD{A,D,E} creates large scale uniformity, which removes error sources.

If MD* blocks your creativity, or helps you only for 5%, and not for 80%, then don't use it.

However, I would count Phonegap, MonoTouch, MonoDroid as code generators, where HTML+Javascript or .NET bytecode (?) are the model. I'm ready to loose some "optimality" in code or performance if I'm on the market after in short time!

The key issues are:
1) use a language that is highly targeted, efficient and precise at describing the systems you want to build (and thus useless for most other systems)
2) generate production quality code that you don't need to look at or touch
3) use a toolset that makes creating the language, generators and models efficient, scalable and maintainable.

Over the last 15 years of working with MetaEdit+ customers, I've seen several dozen cases that fulfill those conditions. In all measured cases, productivity increased by a factor of 5-10 when compared to earlier practices (generally a 3GL with or without UML). Some of those cases and the published research on them are listed here:
www.metacase.com/blogs/stevek/blogView?showComm...

Failing to reach (or even aim for) those 3 targets is what consigns most MDD attempts to mediocrity or failure. Using a tool or language because it's a "standard" or already in use is hardly likely to result in major productivity increases compared to normal. As Einstein said, insanity is doing the same things as before and expecting different results.

There are two sides to learning a new skill: learning what to do, and learning what not to do. In both cases you should try to learn from people who have experience and consistently achieve success. To be honest, there aren't many people like that around for MDD. Most people simply have never seen working MDD, or only cases where the vendor provides the language, generator and tooling (e.g. LabView, Simulink, Mendix). To do it yourself is actually easy enough, providing you listen to advice (even if it may seem counter-intuitive at first).

If you want to give it a try, have a look at our book that explains and teaches Domain-Specific Modeling, dsmbook.com/. For "what not to do", try our article analyzing 76 cases of MDD: www.metacase.com/papers/WorstPracticesForDomain.... The oAW and Mendix guys also know what they're talking about (although oAW is more focused on textual languages, and Mendix on creating one tool for a much broader domain).

And if you do this and succeed or fail, publish what you did so others can learn. Measure how long it takes to build the language, modeling tooling and generators, and compare how fast building the same application is with both old and new ways. The way forward has to be based on hard facts!

I have a different opinion regarding a couple of key factors presented by Jon, based on experiences we have with our customers at OutSystems. In particular:

1. Put MDD in the critical path: Most of our customers start by implementing a pilot project, so they can properly evaluate the tool and the platform. This should be a high visibility project, for sure, but no need to be in the critical path of business - an unforgiving position that gives no slack to the team to learn and make experiments with the new tool. When the team is ready, then yes, go for the critical path.

3. Most projects fail at scale up: We actually witness the opposite. Projects get really interesting when they start to grow both in functionality and number of users. This is where the MDD tool capabilities are put to the test, but it is also where the big value is. You just need to make sure that your tool supports adding functionality to an existing project, changing the functionality that's already there to suit business needs, and that the underlying platform can scale with the growing user base.

Some of the factors I see as key for the success of MDD and its tools are: pragmatism, in the sense that the model should be focused on solving a problem and not be an over-generic catch-all abstraction; extensibility, because there's always something that needs to be added to the language and there are always integrations with external systems; scalability, to support a growing community of users; and built-to-change, because the trick isn't building the first version of an app... its maintaing it fresh for its entire lifespan.

Steve:

You seem to imply that the coverage of the model is 100% and all code is generated. Is this what you meant? Is that a reasonable goal? easy to achieve? If not, how do you define the boundary between the model and the "code".

You also seem to imply that inherently, MDD/MDE is best supported by custom models dedicated to particular solutions spaces. I don't disagree, but I just wanted to confirm that this was what you meant.

Jean-Jacques:

100% code generation is definitely the goal, and the norm is to achieve it. Here, 100% means 100% of the code that is specific to this model. There is of course hand-written code below the generated code: what we call the domain framework, i.e. code specifically written to complement this modeling language and generators, and which doesn't change per model.

In some cases a particular model may need an addition to the domain framework; in others models may contain snippets of code or refer to per-model functions that are hand-coded separately.

If by "custom models" you mean "custom modeling languages", then yes, at least that has been my experience. I'm not sure it's "inherently" true, but I think there are good reasons for it. Have you ever seen a tricky or laborious problem can be turned into something an order of magnitude faster and easier by applying the correct language? If so, you probably understand what I'm talking about. Obviously, in general development those situations were rare, because the right language didn't yet exist. DSM lets you create that "right language" for your needs.

Steve:

thank you for your answer, you are preaching to the choir. I pretty much agree will all your point of views. I talk about "model transformation" instead of code generation, I never need to touch the code, because -say when I am using Xpand- I use the model to parametrize the code within the transformation definition itself (or whatever physical artifact I transform the model to).

I am glad to see this point made very clear, because it is difficult to articulate to management or customers. They always associate "custom" with "bad". As I often say, the way your code is written is "custom", sure you are using Java, but the idioms you use are specific to your team, so in the end, which is easier to learn? a clean "custom" model which elegantly describe the solution, of a pile of mud which only commonality with another pile of mud is the language syntax.

thanks again for sharing your views.

I like Jean-Jacques' phrase "the idioms you use are specific to your team". Maybe we ought to say we develop "team-specific modeling languages" - for a newcomer, that perhaps better gives the impression of targetting a narrow domain than just "domain-specific".

As Dean Wampler said, "Give me a language and APIs that let me express what I need to do very succinctly!" That of course is the whole idea of DSM, and why it is so different from (say) UML-based MDA. It's just a shame that working "code generation" often gets tarred with the same brush as approaches that have failed.

Of course, we're all constrained by what we have experienced personally, e.g. Dean saying that all MDD he has seen has been based on object-oriented languages (I guess referring to UML?). It's just a fact that by nature humans trust personal experience far more than even statistically significant research.

Dean said "Nothing beats a Turing-complete, textual programming language for expressivity and productivity." That may be true if you have to pick one language to use for every single task for your whole life. But for any given problem space, it's simply not true. Expressivity is the ability to say everything you want, precisely and concisely - which is as good a definition of a Domain-Specific Modeling language as you're likely to get. The consistent measured increase in productivity by a factor of 5-10 with DSM is a proven fact. And when you've actually seen DSM in practice, as opposed to code generation with UML or IDE wizards, it's obvious why it is so much faster throughout.

Steve:

I would still recommend using "solution specific model" rather than "team". I was just trying to emphasize that the way people write imperative code if (hopefully) with a "model" in mind. This model that is more or less conscious and consistent is the idioms. Two teams building the same solution might use very different idioms. What is likely is that in any given team each developer will have his or her own set of idioms and the solution construction will quickly look like a pile of mud. As the solution grows and developers come and go, the problem only gets worse.

With respect to UML, I think the problem the industry doesn't see is that the OO metamodel is all but arbitrary. The structure of a class has nothing absolute. As such is has become a hindrance as more and more complex solutions cannot be efficiently described/implemented with a one size fits all concept. Of course all the ingredients I think are there in OO (object, property, method), but it is how they are combined that is inflexible. The tragedy with UML is to think that (abstracted) OO concepts are the foundation of modeling. They built the whole thing on the wrong foundation (MOF). As a result, people are using UML as an M3 layer, because MOF (or Ecore) is simply impractical to use.

On the other hand, the reason why "Nothing beats a Turing-complete, textual programming language for expressivity and productivity." is because it is critical to be able to express actions on elements of a model, the 100% declarative / 0% imperative approach shows quickly its limits. But "Turing complete" is not going to help you much. The key is to understand that each model element has a lifecycle and some other model elements should be able to change the state of a particular model element. This is very difficult to do in an imperative form. It works here and there, but at the scale of a solution, this is where you are loosing productivity in an MDD approach, however, a 100% imperative approach, a Turing complete, approach is not much more productive because you are building this pile of Mud. Brilliant developers don't see the point of MDD because they often code large portions of the solutions with "the" model in mind, but for the mere mortal, a solution, we must find.

For me, the key to MDD is to rethink M3 in order to add the imperative elements appropriately to the model and more importantly specify precisely what goes in these imperative elements. "Turing complete" is the wrong choice. It must be focused on changing the state of model elements and be specific to which model element can change the state of another.

When in OO we say Foo f = new Foo() we start the lifecycle of an object. Modern OO languages can manipulate the lifecycle of classes. You of course don't instantiate a class, you "load" it: Class c = Load("Foo","foo.jar"). For a service the lifecycle could be: Service s = deploy("Bar","bar.sar") s.start() s.stop() s.undeploy()

Each element of the model has a different lifecycle and we can define with precision which element of the model can change the state of other elements (created/deleted/garbage collected, loaded/unloaded, deploy/start/stop/undeploy...). This is where imperative elements are needed in the model. You cannot easily express these transitions from one state to another in a declarative/static way.

I have tried to express these concepts in this article: www.infoq.com/articles/mop

I'll spend some time learning more about what you call a DSM.

You fail to state why MDD means "Big Design Up Front" and "Distance". The article says the very opposite - "bottom up".

My experience of successful MDD is that it empowers the domain experts, not the developers. For a transport solution, a DSL allowed BAs and business people to read (but not write), some of the key logic. The transparency and domain knowledge the developers could interact with was very powerful.

The DSL was made available as a forms based UI, UML Profile, and DSL. All three were equivalent and could be transformed to the other. Developers preferred text artefacts, end users preferred forms, and the BAs preferred UML. All three worked together as different representations of the same information.

Humphrey,

you are correct, people often forget the value of visualizing system behavior, as opposed to be able to specify it.

Come on! Who developed JUnit for you? Continues integration tools? Code analysis? Java itself (or whatever you use). App servers? Do you think if was agile projects with no architecture and no design? You can only be agile becouse other people did thinking, architecting, designing and working for you. If anyone would type code and run with 5 mins interval, you would be in stone age.
MDE exactly allows haisties like you be "agile" ... on the expence of others, who think sometimes, not just type and hit "run".