The following link points to an interesting article (in German):
Groovy-DSLs mit Eclipse-GMF visualisieren
The article perfectly shows some of the issues I have with the current state of visual modeling and
MDSD.
The first part of the article is about implementing a domain concept. This is directly connected to the business problem which should be solved by the software at hand.
The second part of the article is about making the solution of the first part accessible for visual modeling.
I did quite easily understand the first part. The second part however seems a lot like rocket science to me (or some secret ancient ritual). There are a lot of steps and different concepts involved (code, configuration, libraries, guis, wizards, repetitive reflection of the actual domain concept, mapping ...).
While I feel confident, that I learned something from the first part (creating a simple textual DSL with Groovy Builder), I do not have the feeling that I learned something useful from the second part, except that it is very complicated to use GMF...
In my opinion, as long as setting up (and maintaining) visual modeling for a certain concept is so much more complicated than the underlying concept itself, visual modeling hardly pays off!
You really have to evaluate costs versus benefits. And in my experience this is almost never done properly.
In the given article: What is the real benefit of visually modeling the process-chain?
Who is the target? Who will be using the visual modeling capabilities?
Are stake holders really able and willing to grasp the visual models? Or are you still going to communicate with them by Visio and Word?
If it is not for the stakeholders, do developers really like to work with the visual models, or is the simple textual DSL much more preferred by them (easier handling with current tools (refactoring, diffing, versioning ...))?
If you think about these questions, is the effort put into the infrastructure really worth it? The article says itself:
Indeed the learning curve [of GMF] is very steep. [...] To gain a better understanding there is often no other way than explore the GMF-Code with the help of a debugger.
This quote alone would rise a big questionmark if I were the project leader of a project that is actually supposed to provide business value...
In my opinion visual modeling is vastly overrated, and especially in the current state is hardly worth the effort.
In my experience any large-scale modeling efforts often turn very fast into a completely disconnected reality-loop. People are wasting a lot of effort just to conquer the
accidental complexity that is introduced by the modeling requirement. The actual business requirement then comes only at second priority.
The metaphor that comes to my mind is this:
At the beginning you have a business goal, that is like the requirement to cross a river. But once you jumped into the river, you notice, that you vastly underestimated the current.
From now on you are fully occupied to keep your head over the water. Reaching the other side (not to mention at the specified spot) is of no priority at all any more.
Some month ago I was skeptical about lightheartedly jumping into DSL-creation, and I was wondering if I had lost my faith.
It's just funny how there seems to be an accumulation of revolutions lately:
Recently I spent half of a night correcting the consequences of a stupid decision:
Unfortunately I have to come to the conclusion that NetBeans is unusable for me, and I think for any project, that sets a focus on developer testing ...
