That’s a question I never really asked myself, but I do get it from other people every once in a while, when I tell them about Code Generation, the Language Workbench Challenge or just model driven software development in general.
The answer could be summarized as ‘for the same reason a blacksmith needs a hammer and an anvil and a shoe maker needs a boot tree and a needle’. Every tradesman needs the right tools for the job.
Just imagine this: you are working on a piece of software and you find yourself repeatedly going to your customer to ask how they want your application to perform a certain task. Then, you find out that most of the implementations resulting for this are quite similar in nature and you decide to create a small DSL to address that fact and speed up your talks and your development.
Pah! Instead of repeatedly writing the same code, you now write small statements (either graphical or textual) that describe the problems your customer wants you to solve and from which you can generate working software. Nice!
Now, let’s take a step ahead. Suppose you are doing the same thing still, about a year later. Because of your good work, you now have more customers and each of them requests more features than the initial one, because you are doing a good job. In order to cover for that, you have set up a team of developers, because despite the use of DSLs and code generators, you can’t do it all by yourself.
And suddenly, you find yourself in a situation where the small models, because that’s what they are, that you expressed in your DSL start referring to each other, and being (re)used by multiple people on your team. Now which version of which model do you need for product A for customer B, and which one do you need for product C of customer D? And how do you solve the fact that people are making changes to the same model for different products of the same customer?
There are different solutions to that problem, but I reckon most of them involve (re)dividing up the models, and performing version control on them. Maybe even real configuration management, allowing you to mix and match different versions of models. If only you had the tools to support you in that – models are often not stored in text format, like traditional program code, so tools like diff and merge often don’t work, leading to all kinds of issues and additional manual labour.
In a similar fashion, you may run into problems not because your team grows, but because models go bigger – another reason to split them up and maybe start doing version control on the parts. Also, you may find that your models become better if certain parts are expressed in another, dedicated DSL (just think about a DSL for specifying the pages of an app, and another one to define application flow). How do you mix these DSLs in such way that you can easily define the models required to solve your customers problem and generate the code?
This is a very short and possibly rather abstract example, but it is exactly what the case we put up for the Language Workbench Challenge is about. We work with (sets of) domain specific languages, we work in teams, and we work on models that are getting bigger. That will only help us if we can do it efficiently, and if we use tools that help us with issues like the ones expressed above – which are distracting us from our real goal: solving the customer’s problem. These tools are the language workbenches we discuss and compare in the LWC workshop, for the fourth year in a row. So, if you are interested in this topic, because you work with domain specific languages, or are working on a workbench yourself – join us in Cambridge on April 8th, 2014. Registration details can be found here: and information about the workshop can be found here.
And while your at it – it’s worth considering combining a visit to this workshop with a visit to Code Generation, or vice versa.
See you all in Cambridge!