thanks for taking the time to comment!

When I was writing about prejudices, I didn’t mean to express that these were YOUR prejudices, but instead common misunderstandings of many developers out there. And indeed, you never wrote “complicated”. I derived “complicated” from the following piece in your post: “Higher level of abstraction: Developing on this conceptual level is very different to traditional development.”

My post is not so much a criticism of your post, but rather a contribution to the discussion whether MDSD is a feasible development technology.

(PS: don’t know why I had to approve your presious comments, as I didn’t have to approve Ed’s and Ekke’s, but I do hope your future comments will appear immediately)

as Peter points out in the first paragraph, my only conclusion really was that the question if MDSD is faster does not necessarily have a yes / no answer and is not the most important consideration, because there are so many more other benefits on top.

Sure long-term it is faster and if you have everything in place, your next project will be finished in almost no time. Even short-term you might save a lot of time if you have done this kind of development before and know the traps.

And of course, just spitting out a DSL and using only that wouldn’t get you very far, you need to design a alot more.

I’m kind of amused that my post produced so many strong reactions as I just wanted to indicate that time-to-market (most important and quantifyable argument for the management) is not hitting the spot in many cases.

Anyways, nice to have this discussion guys.

(My first comment is still pending)

Yet another excellent post. I so disagree with Magnus’ conclusion even if speed were the most important consideration. Likely I read too much into the conclusion, which I think is based on the premise that MDSD means “design a DSL and use that” whereas for me it also includes design an Ecore/UML/XML Schema model of your data and use that to help jump start your larger application. Even in the DSL case, the flexibility of a DSL is likely to save time and money in the long term if not immediately in the short term.

In the long sight, I think MDSD and DSLs will not only bring quality to your software, but also more time.

To start with MDSD / DSLs I know from my own experiences it needs much more time then traditional programming,
but so many times I later changed some decisions (new ideas, new tools, new frameworks, new technology,…) and then
the power of MDSD allows to do this: change some templates and generate

I would never start a new project without using MDSD and DSLs (with all these good products like openArchitectureWare

ekke

1) I have not used the word “complicated” at all. The aim is of course to make it easier as a whole. And it is for the end-user of your DSL, if your whole toolchain and your metamodel is matured and almost bug-free. BUT the whole process is a lot more abstract, you have model transformations, several code-generation steps and debugging of those processes. My point was that to actually debug, extend and manage the whole process developers need to work differently. To change a specific part of generated code for example you cannot just change it, but must follow all the way up to where it originates. This requires re-thinking when introducing MDSD at the first time.

2) I also do not believe in the fairy tale that business users will ever be able to “write software” or even should, besides maybe specifiying run-time rules with a specific language. I prefer textual DSLs too, but I am a developer. When working with clients who are used to graphical representations it is often useful to have a partial graphical representation that is synronized and shows a birds-eye view of the whole thing. In my experience you end up using multiple partial models for the same application to descripe the particular details of a part more concretely. Event trying a one:one mapping is pointless as you state.

3) Versioning means a lot more and has a lot more potential than having a copy of you model in your version control repository: As soon as your system is in production you are able to track change on a semantic level since you’re using a model. Not only in a diff between two textual representations of your model. What I refer to is for example the simplest of cases of adding a field to an entity. If your model supports semantic versioning you can do all sorts of things with this information, like generating the database migration scripts, automatically handling changed versions of an external (web-)service interface and so on. I have not seen this yet, but have been using it internally quite successfully.

I can only fully agree with your conclusion and will extend my post on certain spots.