hide all comments

DSM

How much effort goes into DSL implementation?

April 03, 2009 15:20:23 +0300 (EEST)

A quite common belief is that it takes a lot of time and effort to define modeling languages and code generators along with supporting tooling. Usually people expect that it will be a project where the effort is counted in man-years. Based on our experience this is not the case at all as we have seen companies to implement DSLs and code generators in days - depending on the domain of course - as illustrated with few cases below:

DSM solution development time

These figures may look surprising - especially if having invested much more time and effort on DSL and tool development. Last month, SYTYKE, a Finnish association on software development, was running seminars on DSM with talks from several companies having defined domain-specific modeling languages and generators. A commonly asked question from the audience was: “how much effort went to implement your domain-specific language and generators along with tool support”. Some answers from the companies were:

  • Ouman: 5 days for modeling and code generation support
  • Sandvik: 2 days for modeling support
  • VTT: several cases with modeling support and generators: few days to 2 weeks

In my opinion these are good, but typical figures. I also know these cases as they used MetaEdit+ for both language and generator definition and for their use. What could then explain the gap between the expected effort and the actual effort? I would like to point out three reasons:

  • The expectations are false simply because not based on any real experience, and perhaps made even without ever having defined languages and generators. The above cases clearly indicate that those having created DSM solutions do not report about man-year, or even man-month, projects. Needless to say, but I tend to believe more those having done it.
  • Being able to narrow down the problem domain where modeling and code generators are applied. If we target too broad or low level of abstraction we end up implementing a general-purpose language - and that naturally takes a lot of time. Also if we don’t know what we are developing it is pretty hard to bring automation in - so we never can start to apply the DSL in a real project.
  • Wrong tooling is used requiring extensive use of resources for developing the language, generator and modeling tool support. The horror story I heard at OOP conference was a talk reporting having used 25 man-years to define modeling languages and tools with Eclipse EMF. I don’t think there are many companies who can make such an investment. One easy to read and understand example on tool differences was reported at OOPSLA workshop on best practices for MDSD (Model-Driven Software Development).