Keynote at Code Generation 2014: The business cases of modeling and generators

There is no business case for modelling and generators – only for a specific language and generator in a specific situation. The right language in the right situation can improve productivity by an order of magnitude; the wrong language will reduce it. So what makes a language “right”?

In this talk we look what kinds of modelling languages and generators tend to be more beneficial than others –from the early days of modelling right up to the latest research. Getting more out of the models than their original creation required, raising the level of abstraction and addressing a specific need seem to be common characteristics of successful modelling and code generation approaches.

To evaluate the full business case we also need to look at the costs and benefits of creating languages, generators and tools. By applying the above principles to language creation itself, we can improve the quality of the resulting modelling language, whilst lowering the time and effort needed to create and maintain it. Other features important to the language developer include enabling tools to support language evolution, and improving tool scalability to tackle larger systems and teams.

@MarkCamp2: did you read the rest of the first sentence: 'There is no business case for modelling and generators – only for a specific language and generator in a specific situation'. JP and I are certainly proponents of modeling, we're just saying that you can't really make a business case for 'modeling' without stating which modeling language you're going to use.

I definitely agree on the importance of a shared understanding of the requirements. Domain-specific modeling languages should generally be in the language of the problem domain. Rather than have the requirements in a Word document or text fields in DOORS, a good DSM language lets you specify a more precise and often more easily created description of what the system will do. Not every requirement can be expressed in such a nice way, but those parts that can be, should be.

@Jouko: Thanks. The references mentioned in the slides describe more details on these gains.

@Mark: I advocate modeling too, but for me the value of modeling and using generators depends on the case and on the type of languages applied. In some cases the productivity gain can be 1000% compared to no modeling or over half of the errors are prevented because of using correct modeling languages. Models provide naturally big value on communication, building understanding etc but that is hard to measure…so in Code Generation Conference I focused on those aspects that are easier to measure. If you know about studies that measure the more “softer” side: communication, understanding, teamwork etc I would be more than interested to read and learn more.

I don't agree. I think there is a strong business case for modeling. Here is why I think that.

First, I think the consensus is that IT projects are mostly failing to meet objectives. I've seen a lot of anecdotal evidence and some convincing studies (of federal contracts, over half fail), and not a shred of contrary evidence.

My own experience confirms this conclusion. Every enterprise and every department that I have encountered is failing to identify requirements thoroughly, concisely, clearly (to the users), and accurately, leaving no hope that tool generation, no matter how well it is done or how it is done, succeeding. If you don't have an accurate user-understandable description of the problem, then there is no way for the implementers to solve the problem.

The primary cause of failure is equally firmly established...poor identification or communication of business and user requirements. In other words, most projects fail, and most of the failures are due to modeling failures. I don't think it would be hard to proceed from those facts to the conclusion that there is a business case for solving the problem, i.e., completing the modeling phase successfully. It would lead to at least the possibility of success, and its absence is leading directly to failure to provide a return on investment.

4.
Gains
 “The work that earlier took a whole week, is now done
during an afternoon”, an engineer at Elektrobit
 The measurement (n=6) revealed that Domain-Specific
Modeling solution was on average 10 times as productive
as the current development approach, study1 at Polar
 Productivity improvement is 289%, study2 at USAF
– Over 130 tasks, both initial development and maintenance
– The differences in the average performance of the subjects
are statistically significant at confidence levels exceeding 99%
1) Kärnä, J., et al., Evaluating the Use of Domain-Specific Modeling in Practice, Workshop on DSM, 2007
2) Kieburtz, R., et al. A software engineering experiment in software component generation, ICSE, 1996

16.
Incremental language development
 Nobody gets the language right at the first try!
 The best way to build languages is in incremental steps
together with language users
• Language defined
disconnected from the users
• Language defined as a spec
on paper
• Partial, like plain schema
• Language changed without
considering work done
• Language users are
directly involved
• Each “unit” of the language
tried out in the real world
• Influence of language
change checked against
other parts of the language

20.
From products to projects
Product development
 Apply many times
– Several apps/features
 Maintenance
 Predictability
 Initial investment
shared over time/
products/variants
Projects
 Apply mainly for the
current case
 Next customer?
 A single project does not
usually have a budget
for language and
generator development

21.
To apply languages and generators
in project organizations…
 Build them fast
 Accept uncertainty on the language constructs
 Be ready to change frequently
 Be ready to throw away, and start another
 Allow language users to participate
 Language Workbenches must support project
organizations too!