Introducing a tool successfully

A couple of concrete steps to take

A customer recently asked me this: “We still lack a bit of acceptance among our users for the DSL. Can we chat a little bit about ways of teaching them how to use MPS and the DSL?”

I suggested to ask their colleagues in their sister department, because they seem to be quite successful with it. For all of you who don’t have the luxury of just asking colleagues, here are some pointers of what to do.

Three Preliminaries

First, I don’t think any of what I am going to say is a) a huge surprise and b) specific to DSLs. It is tried and trusted techniques of introducing something new into an organization. The more disruptive the change is, the more critical is a structured approach of introducing the change. And DSLs certainly are disruptive.

The second preliminary is that all of what I am going to suggest won’t work if the new tool or approach isn’t any good. Make sure that your “new thing” actually fits with the work your users have to do. It’s ok to be disruptive, but you have to disrupt with something really good. Otherwise you have no chance.

Third there’s politics, some folks’ general lack of motivation to change and all kinds of other psychological things to consider. I won’t cover these things here; we assume the set of users you want to “convince” is not unreasonably opposed.

So let’s now look at how the successful department did it:

Introductory Workshop

We had developed the first version/release/prototype of the language with the help of two domain experts. They were part of the language development team, and helped us make sure the language was reasonably close to the domain. After we build a few prototype models using the language with these two, we decided we were ready for a wide audience. IIRC twelve additional users were scheduled to learn the tool next. We started with a multi-day workshop where we explained the idea, gave an overview over the language and then developed a few example models from their specific sub-domain. Didn’t all go completely smoothly, but at the end of the week I think there was general agreement that this new thing isn’t completely crap and might actually simplify their work.


The next ingredient is a champion; her role is to act as a bridge between the language development team and the (growing) user community. She acts as the first level support for questions from the users and works with them during the initial use of the tool. She is also part of the development team’s Dailys and requirements discussions, and she validates a new release before it leaves the barn. Every two weeks when we release a new version of the tool, she writes a release notes document that explains the new features, required manual changes to existing models, or automatically executing model migrations. Every week she also moderates a Q&A session where the users can ask questions; a representative of the developers is also part of this meeting, so devs and users can discuss technical issues directly.


Nobody uses the tool alone during the first phases of use. At least two, sometimes even larger gaggles work together. As we all know, it is easier to avoid getting stuck when you’re not sitting in front of the box alone.

Quick turnaround

No tool is perfect. Especially not one which tries to “inhale” the semantics of a non-trivial domain. An important ingredient to successful adoption is that the turnaround time based on user feedback is reasonably quick. Nothing is more frustrating if users find a problem or something that doesn’t fit their tasking, and then nothing happens for weeks and weeks. Larger changes of course take longer (and often need quite a bit of discussion to identify the right abstractions), but you can win a lot of hearts and minds if small (and annoying) problems are fixed quickly.


So basically that’s it. Quite obvious, isn’t it? It one of these things where the problem isn’t that these things are hard to come up with; it’s more a matter of just doing it, systematically.