Why DSM?

The most pragmatic reason to use DSM is simply the increased productivity.
Industrial experiences have consistently shown DSM to be 5-10 times more
productive than current software development practices. But why is DSM so fast?

Improving developer productivity

According to Software Productivity
Research, the average productivity in Java is
only 20% better than in BASIC. C++ fares no better than Java. In fact, with the
exception of Smalltalk, not a single programming language in general use today
can show a substantial increase in productivity over BASIC.

So after all of the language wars, objects, components, and frameworks, we
are still scarcely more effective than 20 years ago. However, go back a couple
of decades more and there is a radical change: a leap in productivity of 400%
from Assembler to BASIC. Why was that leap so big, and how can we achieve it
again today?

The 400% increase was because of a step up to the next level of abstraction.
Each statement in C++, BASIC or Java corresponds to several statements in
Assembler. Most importantly, these languages can be automatically translated
into Assembler. In terms of productivity, this means you effectively get five
lines of code for the price of one.

Did UML increase productivity?

Traditional modeling languages like UML have not increased productivity, since
the core models are on the same level of abstraction as the programming
languages supported. One day of UML modeling produces a day's worth of code -
but you still need to go in by hand and add or edit the majority of the code.
You're trying to maintain the same information in two places, code and models,
and that's always a recipe for trouble. Ever seen anybody hand edit Assembler
and try to keep their C++ code in synch with it?

Of course, UML has its benefits: the visual presentation can be read much faster
to get an overview, for instance. But one look at the ongoing development of UML
speaks volumes. Half of the world finds that UML cannot represent what they need
in their models, and so want to add something to it. The other half says UML is
too complex, and want to reduce it down to its core elements. UML tries to be
all things to all men, and thus cannot raise the level of abstraction above the
lowest common denominator.

Current MDA tools are based on UML, and thus suffer from its problems. Even a
tool vendor sponsored study
only found an increase in productivity of 35% compared with hand coding.

Domain-specific modeling for productivity

How then can we raise the level of abstraction? The last OOPSLA, the leading
software engineering conference, put forward Domain-Specific Modeling as a
solution. Similar statements have been uttered recently by Bill Gates and Grady
Booch, among others.

Domain-Specific Modeling raises the level of abstraction and hides today's
programming languages, in the same way that today's programming languages hide
assembler. Symbols in a domain-specific model map to things in the domain - the
world in which the application is to run. This is a whole level of abstraction
higher than UML, and makes each symbol worth several lines of code. The
application is automatically generated from these high-level specifications with
domain-specific code generators, aided where necessary by existing component
code.

As the name suggests, Domain-Specific Modeling is only possible because it
narrows down the design space or domain, often to a single range of products for
a single company. This is
bespoke tailoring rather than UML's "one size fits all", and it results in significantly higher quality. Unlike
traditional bespoke tailoring, though, the process can be automated. Standard
'tailors' can simply enter the information in the form laid down by the master
tailor, and the product can be automatically created.

The master tailor - an expert developer - defines a domain-specific language
containing the chosen domain's concepts and rules, and specifies the mapping
from that to code in a domain-specific code generator. In effect, all he is
saying is "this is how I look at the world of our products, and this is how
I write code for them." The other developers then make models with the
modeling language, guided by the rules, and code is automatically generated. As
an expert has specified the code generators, they produce products with better
quality than could be achieved by normal developers by hand.

Most importantly, making the models is much faster than writing the code by
hand. Industrial experiences at leading-edge players like Nokia and Lucent have
consistently shown development becoming 5-10 times faster. For the first
time since the step up from Assembler, companies can make a major productivity
leap. For those doing it first, the competitive advantage is substantial.