On Monday I had the pleasure of visiting Ed Merks (leader of the Eclipse Modeling Project and founder of the Macro Modeling company ).
Among many other topics, we discussed some of the reasons developers use as excuses for avoiding modeling during the development process. At that point he reminded me of his (and Peter Friese’s) presentation about The Unbearable Stupidity of Modeling , where he lists all typical arguments against software modeling and tries to dismantle them one by one.
If you have not seen this presentation yet, now it is the right time to do it!
Of course, if you are skeptical about modeling, I don’t expect you to be convinced just by a set OF slides (without the explanations and the chance to discuss with Ed himself). Nevertheless, I think the presentation is interesting enough by itself to give it a try.
My own opinion on this topic has been already discussed in this portal a couple of times before, see this blog post and also this page .
FNR Pearl Chair. Head of the Software Engineering RDI Unit at LIST. Affiliate Professor at University of Luxembourg. More about me.
Nice presentation!
I think that the statement that “tools are orthogonal to your process” is somewhat devoid of reality. Tools will always shape your process to a large extent, because the tools’ capabilities will dictate the limitations of the process. Having said that, the tools’ capabilities can also have the reverse effect: with added capabilities, the process could be optimized.
Also, modeling typically impacts the process quite a bit. E.g., code generation implies an extra step in the build and if the code generation is not 100% and/or the generated code must interoperate with manually-crafted code then you should have an extra process step when pushing a new version of the model. Furthermore, MDD allows you to pull the progr^H^H^H^H^Hmodeling towards business analisty types instead of “true” developers and that will change the process as well.
modeling main drawback is not killing creativity but limiting specificity
Not sure I get what you mean by “limiting specificity”. Care to ellaborate a little bit more? Thanks!