Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
18  
I am a true believer in no programming or development methodology. Almost all of them are useful for something; none are best for everything. I don't believe that a "true believer" question is constructive by P.SE's standards. –  David Thornley Mar 7 '11 at 22:56
1  
@David Thornley: Thanks for the comment but I don't know if the "true believer" had anything to do with being constructive or not. I am very happy with the answers and it helped a lot. From my point of view it was very constructive. Also I do believe there is a lot of value in a lot of the answers for a lot of people interested in MDD. –  KeesDijk Mar 8 '11 at 7:06
show 1 more comment

closed as not constructive by Mark Trapp Nov 9 '11 at 12:13

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

17 Answers

up vote 50 down vote accepted

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.

share|improve this answer
14  
Fred Brooks called it, "No Silver Bullet," but the essence of your point and his argument are identical: cs.nott.ac.uk/~cah/G51ISS/Documents/NoSilverBullet.html –  Adam Crossland Mar 7 '11 at 20:10
5  
KeesDijk: IMO, handling repetition is the very core of programming itself. Most structure elements in programming langauges, from loops, recursion, functions to OO concepts etc. are made for handling one kind of repetition or another. –  user281377 Mar 7 '11 at 20:14
3  
Fred Brooks has some papers from the 50s and 60s that have yet to be debunked. Check out the book "Mythical Man Month" (which includes the "No Silver Bullet" essay as well. –  Berin Loritsch Mar 7 '11 at 20:20
4  
1987? Heck, Fred Brooks published a book in 1975 that has lost none of its importance or accuracy(en.wikipedia.org/wiki/The_Mythical_Man-Month). No, I don't think that the principles of No Silver Bullet are any less true today than they were then. As @ammoQ so succinctly put it: there is some inherent complexity in software development..." Now, you can try various approaches and techniques, frameworks, methodologies, but for the most part, they just try to shove all of the complexity into one particular bucket. It doesn't go away. –  Adam Crossland Mar 7 '11 at 20:25
4  
@KeesDijk: The idea behind "No Silver Bullet" isn't going to be obsolete any time soon. Brooks divides programming difficulties into the essential and the accidental, using terms from philosophy. His premise is that there is a lot of essential difficulty in programming, and all new methods really can do is eliminate the accidental difficulties. In that essay, he says the most dramatic development was shrink-wrap software, which compared to custom or customized software is a whole lot of programming that just doesn't have to be done. –  David Thornley Mar 7 '11 at 23:00
show 9 more comments

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 :-)

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
show 1 more comment

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.

share|improve this answer
add comment

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.

share|improve this answer
show 2 more comments

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".

share|improve this answer
2  
Brooks was arguing that what, 30 years ago? –  Paul Nathan Mar 8 '11 at 2:47
show 1 more comment

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.

share|improve this answer
show 1 more comment
  • 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.

share|improve this answer
show 1 more comment

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.

share|improve this answer
show 1 more comment

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.

share|improve this answer
show 3 more comments

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.
share|improve this answer
show 2 more comments

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.

share|improve this answer
add comment

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)

share|improve this answer
show 1 more comment

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?

share|improve this answer
show 5 more comments

Not the answer you're looking for? Browse other questions tagged or ask your own question.