Steven Kelly on DSM

There's an interesting discussion on the name DSM in the DSM Forum discussion group (join the DSM Forum group on LinkedIn for free to see it). Stefan Hägglund started it, and his questions and my answers are below:

@Stefan: "I've always viewed DSM as belonging to the problem domain. However, recently I've seen DSM being positioned in the solution domain [too]. What do you guys think?"

DSM is all about raising the level of abstraction higher than the level on which we currently build solutions. We always aim at modeling the problem domain: the more we include solution domain information in the models, the leakier the abstraction becomes. If the modeling language concepts are entirely from the solution domain, it has not raised the level of abstraction.

Some people like to build DSM languages starting from a solution framework and abstracting upwards. I find that's often less successful than starting from the problem domain and working downwards, but it is still possible to arrive at a decent problem domain modeling language.

@Stefan: "[If we take] the acronym purely from a semantic perspective, DSM means Domain Specific Modeling, period. If we wanted it to be specifically Problem Domain Specific Modeling, why didn't we call it PSM?"

I think I can speak to that, since I'm one of the guilty parties behind the name. First some background in terms of semantics: no word contains its meaning. That's a fundamental, and should be clear: there's nothing in the sound "cat" that is particularly cat-like. (Since onomatopoeia is unlikely for DSM, let's skip that exception!). We should of course strive in a name for something that uses existing concepts to help get the point across, but it has to be short enough to be used: the name can't be the full explanation.

Why DSM then? Back when we were looking for a name, we looked at existing names and fields. Our own background was in CASE, in particular metaCASE, but that term was only familiar in Europe, and "CASE" worldwide had bad connotations from the overly hyped failures of tools around 1990. DSL was clearly similar, but we needed to distinguish what was different: we were talking about graphical modeling languages. Since some of the languages were matrix-based, we preferred "visual" to "graphical", and the first BOF and workshops at OOPSLA were called "Domain-Specific Visual Languages". That was already a bit of a mouthful, and tended to make people think of "Visual Programming", something else which in most people's minds had been seen to fail. We thus shortened the name to "Domain-Specific Modeling", which also used the widely accepted semantics of the word "modeling" in our community. As shown by all the MD* names, modeling was seen as a key element in moving our field forward. The key differentiator from the other MD* approaches was domain-specificity: the focuses on problem domains, visual languages, code generation, domain frameworks, tooling etc. were important elements, but not as important to DSM as domain specificity, and not as useful in distinguishing it from other approaches.

The term DSM had already been used early on by the GME guys at Vanderbilt, although they had later moved to calling it "model integrated computing". Overall, as a term I think DSM has done OK, although of course something shorter and containing more information would have been better :-). Part of the problem is its very success: remember when O-O was the buzzword, and everything had to be O-O? Back then I remember an advert talking about an "object-oriented user interface", and predicted that DSM will have reached a tipping point when we see the first mention of a "domain-specific user interface" (where D-S is used more for its buzz than its semantics). That happened last year, and Google now has nearly 100 hits for that phrase! When something becomes a buzzword, people want to apply it to their own work even if it doesn't quite fit. There's not much anyone can do about that other than accept it as the price of success: rather that, than that nobody else ever mentions DSM.

However, what we should IMHO try to avoid is accepting those uses of "DSM" as changing its core meaning. If we do that, it becomes devalued and diluted, and most importantly when people apply these other non-DSM approaches, thinking they are DSM, and find no productivity improvements, they will perceive DSM as having failed. To my knowledge, no "pseudo-DSM" has raised productiviy by a factor of 5-10, or even close, whereas for true problem-domain based DSM this is common.

So, I don't want to be the language police here, but if as Stefan says, we have "always viewed DSM as belonging to the problem domain", let's stick to our guns and continue to promote what we know works.