Why aren't we all doing model driven development yet? [closed]

Question

I am a true believer in Model Driven Development, I think it has the possibility to increase productivity, quality and predictability. When looking at MetaEdit the results are amazing. Mendix in the Netherlands is growing very very fast and has great results.

I also know there are a lot of problems

• versioning of generators, templates and framework
• projects that just aren't right for model driven development (not enough repetition)
• higher risks (when the first project fails, you have less results than you would have with more traditional development)
• etc

But still these problems seem solvable and the benefits should outweigh the effort needed.

Question: What do you see as the biggest problems that make you not even consider model driven development ?

I want to use these answers not just for my own understanding but also as a possible source for a series of internal articles I plan to write.

Answer 1

There is no golden hammer. What works well in one domain is pretty useless in another. There is some inherent complexity in software development, and no magic tool will remove it.

One might also argue that the generation of code is only useful if the language itself (or the framework) is not high-level enough to allow for powerful abstractions that would make MDD relatively pointless.

Answer 2

Interesting question! I admit, I'm not a fan, but then I've tried to use model driven development several times in projects that fit some of the issues you just raised.

Here's my reason list:

• learning curve - modeling tools have been evolving so rapidly, that I'm hard pressed to find engineers that deeply understand the tool. I still find you are only as good as your modeling tool. Admittedly, many of the issues below could track back to this one problem - whenever you think a tool is too limiting, it's possible you don't know it well enough.
• Too structured - Personally, I've been in situations where I found that the modeling tool was simply too structured to let me describe everything I needed to describe. And once I switch over to drawing some peices of the model outside the tool, things quickly decay as people start drifting outside the tool to find the information.
• Cost of tuning the tool - every time I've tried to autogenerate code, I've ended up manually reworking the code once I see what the tool thought was right. I know after a few go arounds, this issue diminishes, but that means you have to survive the first few go rounds. I have generally felt that we were playing whack a mole - make model -> generate code -> fix code -> update model -> fix model, rinse & repeat.
• Model Configuration Management - since the model describes large parts of the project, at some level the model CM will be more cross cutting than the built code. Compartmentalizing the modeling files is an art in itself - do it wrong and you often end up with developer deadlock, or out of date models as people give up and go down to the code.
• time to market - I've experienced definite problems when in a situation where the need for working software was urgent. If the project and team are small enough, I see no reason to waste time on a modeling tool when the time can be spent coding and testing. Not every project is big enough to require such investment.
• Cost of failure - when I've seen projects run away from modeling tools, it's because of the high cost of failure - to use the tools, you need every developer to be involved. That's a big investment in training and hands on learning, and a very costly mistake if someone has set up the model badly. My experience is that it can take two or three releases to get the model right - so many projects don't survive modeling mistakes long enough to realize the benefits.

Answer 3

It's been cited already, but No Silver Bullet addresses the point pretty well:

The essence of a software entity is a construct of interlocking concepts: data sets, relationships among data items, algorithms, and invocations of functions. This essence is abstract in that such a conceptual construct is the same under many different representations. It is nonetheless highly precise and richly detailed.

I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation. We still make syntax errors, to be sure; but they are fuzz compared with the conceptual errors in most systems.

If this is true, building software will always be hard. There is inherently no silver bullet.

Later, Brooks points out the following about the concept of "automatic programming":

For almost 40 years, people have been anticipating and writing about "automatic programming," or the generation of a program for solving a problem from a statement of the problem specifications. Some today write as if they expect this technology to provide the next breakthrough.

Parnas implies that the term is used for glamour, not for semantic content, asserting, "In short, automatic programming always has been a euphemism for programming with a higher-level language than was presently available to the programmer."

He argues, in essence, that in most cases it is the solution method, not the problem, whose specification has to be given.

Basically, I'd argue that MDD is just another euphemism for programming with a higher-level language than was previously available.

That's not to say that programming in a higher-level language can't help -- in fact it often can. But the essence of the problem remains the same: no matter how great a tool or how great a language you are using, at the end of the day you need to think through all the problems and solve the issues. The best any tool or any process can do is remove the "fuzz" so you can focus on the important issue, which is, as Brooks said, "the specification, design, and testing of this conceptual construct".

Answer 4

Because not all programming is object oriented, which all MDD tools seem to expect. UML itself is based on the presumption of objects. Sure you can use sequence diagrams to model functions, but many times that is clumsy.

Because there are programmers like me who get more progress and results from TDD than MDD.

Because Modeling != Programming.

Because the cost/benefit was too high on the cost side and not enough on the benefit side. This has probably changed since I last looked at MDD, back then you would be required to pay > $6000/seat (USD) for a tool that would be moderately capable of MDD.

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.

Those are some of the reasons why I personally don't do MDD. I've been exposed to it, but nothing has been able to make me a convert. Perhaps I'm too old school. Perhaps I'm too new school (whatever that is). It's just not a tool that I've been able to make pay for itself.

Answer 5

Because of a simple law that affected all these modelling tools, you know, CASE, UML and such:

Getting between a programmer and his code is very costly.

If you do so, you need to build a proper compiler/interpreter, code generators result in terrible workflow and terrible feedback to the programmer (error messages and such).

One of the great insights of Domain Driven Design is that Models should be in code, not in something external to the code.

Ultimately the question is: Why don't your models fit into code? If you're doing embedded development and are stuck with C or need to generate code for different platforms, code generation may be worth the cost. For everyone else, a more powerful programming language and better code design are usually better than designing the code in something other than the code.

Answer 6

Microsoft/Apple/Google isn't pushing it :)

What kind of development gets popularized has much to do with tools, backer and evangelism. It's very hard to break through with something without having a big backer (Ruby on rails perhaps being the exception but it's still small compared to Java/C#/Python)

Answer 7

• Seems like a gigantic hassle for very little benefit.
• I always seem to be dinking with edge cases and strange things, the magic stuff never really seems to work right.
• OO ain't a silver bullet; blobbing a software-generating methodology onto OO doesn't make it silver.

But I'm not fond of enterprisey solutions in general.

Answer 8

I had the discussion, and would love to do MDA, but the biggest drawback is tool support for now. I am using a derivation of MDA which I like to call "Runtime Model evaluation", but more on that later.

The drawbacks of MDA are, as I know:

• Missing Refactoring Support: Lets guess I want to model the entities of my datamodel with MDA (Typical usecase No. 1). If I have my model in, lets say, an UML diagram, and I change it, nothing of my code changes with it (at least the generated classes), and instead of having still a working app with better named attributes, I get a lot of errors I have to correct manually.
• Missing debugging support: Usually translations from model to code are done by having some transformation language at hand. This would be no problem usually, but when we debug, we optimally should not be worrying of the code we generate, and a debugger should step into the transformation model. Instead it steps into the generated code, and as we all know, the transformations should look good, not the generated code. Okey, we can pretty print it, but in an optimal world the generated code is a compiler artefact, and should never have to be opened in an editor for a debugging session (I could live with it, and this argument is a bit theoretically, but it is one reason against MDA)
• Coded models are easy: In other examples, the Model could model some domain aspect, and which is then compiled into code. Yes, it is MDA, but most MDA models are just sophisticated configuration files, which could easyly be handled at runtime.
• Transformations are hard to test: If you use transformations in a specialized IDE, they are done by the IDEs "compiler". But the transformations have to be seen as part of the code of the application, and as such should also undergo the test and code coverage requirements of the app.

What I currently prefer is "Runtime Model Evaluation" (if someone knows an accepted name for this please enlighten me). My entities are stored in ordinary Java classes, and everything I need to "model" is made by annotations I read at the start of the app. No transformations needed, it was just a bit hard to get my meta model right.

Everything else is either done with property files or XML for hierarchical data. If you have a model, it is always hierarchical, so there is nothing you can model which you cannot also express with XML. And if you need a special model editor, which you probably will have to write also, you can as well build an editor which even works at runtime of the app, and makes the app more configurable than everything you could model.

Answer 9

I feel that most people using Fred Brooks' No Silver Bullet to explain why people aren't doing MDD are missing the point that Brooks makes. Sure, the final conclusion is that the actual, intrinsic complexity in developing software will never go away and so MDD will not solve this.

But one reason that Brooks even discusses this intrinsic complexity is to compare it to the large amount of time we typically spend fighting with languages, libraries and tools, i.e. not dealing with the intrinsic complexity of the problem we are trying to solve. So this is exactly where MDD shines: cutting away all the fuzz and creating a tailored language, model or other formalism to deal with the real complexity at hand.

So from this perspective, No Silver Bullet is an excellent reason to invest in MDD. That is, if it weren't for the problem that I believe hampers MDD adoption: the actual development of a model-driven environment that allows you to focus completely on the intrinsic complexity of the problem you are trying to solve is much more difficult than just solving the problem in a general purpose language directly. Mostly because the existing MDD tooling is extremely complex.

Compare it like this: it's much easier to write a program in C than to write a C compiler. Instead of just solving a problem and dealing with the cruft in a general purpose language, making an MDD environment for other developers requires you to basically write a program that solves all possible cruft-related problems in the problem space up front. That's quite challenging.

Answer 10

To my knowledge, MDE and MDA do not sufficiently address the needs of the embedded controller developer. Models can certainly be used to describe a system, but I don't think the embedded developer is ready to trust the model to deliver the best, or even correct source code.

There are a number of plug-ins for Eclipse that let a developer use either the model to create/update Java code, or the Java code to create/update the model. This seems like a handy tool. Unfortunately, all my development is done in ANSI/ISO C, and there are no plug-ins, that I'm aware of, that would allow me to do the same thing.

Furthermore, how can a developer instruct the model to implement the code as an event-driven HSM, or some other design pattern, over any other design pattern (or anti-pattern)? If the code is manually updated to use an unknown design pattern, can the model accurately depict that?

How do you implement those functions that don't fit into a model?

Answer 11

Short answer… because model driven is often related to code generation and code is fragile; what we need is code elimination and model driven is surely the way to go.

Some have dismissed the question arguing that there is no golden hammer and that software development is inherently complex.

I fully agree with them that there is no golden hammer but I don’t think that model driven is a quest of golden hammers or silver bullets!

I would like to go further with complexity; there are two sorts of complexity one which I call organic or natural complexity, complexity that is inherent to the business and its processes but we also have ceremonial complexity.

Complexity that creeps into the system instruction by instruction, day after day. Ceremonial complexity - unnecessary complexity - emerges essentially from uncontrolled mangling of technical code with business oriented code, but also from lack of structure and uniformity in the system.

Today the entire complexity that haunts the development of information systems and causes failure and waist is ceremonial complexity; complexity that can be eliminated.

Ceremonial complexity is waste, waste caused by code, value less, change adverse, invariant code; code that must be reduced to its strict minimum.

How to do that? Easy!just don’t write it, and don't generate it, in the first place!

Necessary, invariant technical code; code that is used for reading/writing, displaying, communicating… That’s where models get in, by describing the logical structure of data - I would add in a relational way - models can enable generic handling of standard reading/writing, displaying and communicating of data.

It’s just like an operating system, you don’t rewrite it for every project you use one. So what is needed is a technical engine that handles invariant aspects of software given a model. I call it an AaaS (Architecture as a Service) engine.

As for unnecessary code, well it is unnecessary code so might as well leave it unwritten.

That leaves us with necessary, business oriented code that should be written, necessary business oriented data that should be designed and necessary user interface and experience that should be designed and imagined.

By eliminating fragile code, we can embrace Architecture as a Service a new paradigm for software development based much more on modeling and design than on code.

Answer 12

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.

Answer 13

MBSE - Model Based Software Engineering is the more pertinent term.

Putting the issue of the various tools which are in effect point solutions, MBSE requires a different project workflow. The DSML (domain specific modeling language) needs to be at the level of abstraction required to effectively communicate the requirements for review with the stakeholders. Then you need to transform the model through ever increasing levels of refinement to eventually generate code.

When you have the DSML and transformation / generation processes fully and correctly implemented then the generation of artifacts comes at very low cost. But until you reach that stage of debugged tooling it is very painful.

Most of the success stories for MDD are in the area of Product Line Engineering (PLE) where a succession of similar products are generated using established tooling. Of course, many of the Java code generators are really simplified versions of MDD. Some XML in and generated code out.

Answer 14

Model Driven Development is a non sense because this is a top down model to code approach. It is impossible to create full running application just from a model and therefore MDD is useless!!

What I do is to only use UML at higher level of abstraction to create the skeleton of my application. I mean create Packages, classes etc... then start immediately to code in Java language.

I found that live synchronization with tools such as Togethersoft, Omondo were really useful when I first time start modeling in 2004. A new stage has been recently introduced by Omondo which is a kind of mapping between Java, model and database ID. Really powerful and it works well in my projects.

My UML diagrams help me now to speed my project and are not anymore useless :-)

Answer 15

MDD adds another step to the development process, which is a downside in situations where there is no good model and the first unpredictable or nearly broken partial solution to market might well win the most marbles.

Answer 16

It has been holly grail to have executable business process models. In theory you wouldn't need programmers for that at all. Practice shows, that with MDE, that getting actual model to work it's just as complicated as writing code.

I'd say for experienced developer it would be much easier to fill in classes generated from UML, than to bother with for example ExecutableUML. On other hand, for ExecutableUML you need significant amount of computer-science knowledge, so you can't count on business manager creating that on his own. In theory he would just combine ready blocks (classes), but actually the "glue" is what causes problems.

Also, usefulness of MDE is limited to systems with lot of component reuse.

Answer 17

You wrote:

I also know there are a lot of problems... projects that just aren't right for model driven development (not enough repetition)

If your code is repetitious, then either you have chosen a poor programming language, or you are using it badly. With better languages, there is no need for repetition. Consider the Ruby Active Record library. Database tables are created by writing migrations. There is no need to repeat the schema definition in any other place. You don't have to define a class with data members corresponding to the table columns. A single line of code connects a class to a table.

I view model driven development as a complex and inefficient work-around for weak programming languages.