The cost of building DSL / DSM tools

Most of the costs of developing software are attributed to the maintenance phase (often I hear 80%).

I never heard anyone disagree with that.

It makes sense to get your design right from the start - as mistakes in the design phase are normally the most costly ones to solve later on - a good initial design, though, does not eliminate or necessarily reduce the amount of cost that goes into the maintenance phase.

Often I hear the question on how software development with DSL's relates to this wisdom. It's a good question with a simple answer, but there is a better question.

The simple answer first: DSM languages (or: DSL's) aim at development on a more abstract level. The maintenance work, therefore, is also done on a higher abstract level, making performing this work more effective and thus less costly: a change in requirements is much easier to implement. When it comes to getting the initial design right, DSM languages provide better support than general purpose modeling or programming languages: The "wisdom" of the expert and rules imposed by the underlying architecture are (or should be) encapsulated in the modeling language and prevent silly designs. This does not mean that the developer can be a brainless chimp, in fact the more knowledgeable he/she is about the problem domain the better (just like when not using DSL's), but the support he/she gets from the language in getting the design right simply is more prominent.

The better question, however, focuses on the tools for implementing DSM languages and generators (or MDD if you will):

How does the issue of maintenance and "getting the design right" relate to DSL tools?

Why should building your own model-based code generation tool (or tool-chain) be any different when it comes to the design and maintenance issue? Isn't it likely that 80% of the cost of building your DSL tool (or MDD tool chain) will come down to maintaining it? I dare say that the 80% is a rather mild estimate.

Sure, you can get an MDA tool, based on the industry-standard UML language. You will draw complicated pictures, outdated immediately, you won't generate anything useful and you will have very little tool maintenance. You can claim you do MDD but you never even have the time do it or to evaluate the true MDD alternative because you're so darn busy all the time maintaining your code. For you, reverse engineering must be a blessing...

With DSL/DSM tools you shift (most of) the maintenance effort to the language (and generators) you are using. Just like your code in software development today, now your modeling language(s) and generator(s) will need maintenance: You will not get them right immediately and even if after a while you get them right you will still need to change them later on.

So, are we no step further with DSM? Do we just shift the maintenance work to another, more abstract level? No, with DSM less developers will do the maintenance work, preferably the smarter ones and their work helps the less-smarter ones (who are still smart, just a bit less) do smarter things faster.

When using DSM/DSL technology correctly, the major chunk of your work over time will be focused on updating your modeling languages and generators. In my opinion it makes sense to choose a DSL/DSM technology that supports this fact: You do not want the majority of your developers to wait for a couple of days/weeks until the expert provides them with a new, thoroughly tested version of the modeling language, do you? And what about having your developers manually update all models made with the previous version of your modeling language when a new version comes around? That's a lot of maintenance work man. You can claim you're doing DSM or DSL or even that you have a Software Factory, but the factory sucks, and you probably do not have the time to claim it.

Microsoft have a pretty good solution to this problem with their DSL tools: A factory for making factories. I do hope they improve it though as I hear it does have some significant drawbacks. It's been ridiculed but they did think a lot further than the people doing the Eclipse GMF/GEF. The latter have not even started thinking about the maintenance problem, making the framework ideal for code-savvy pet-techies who just like to build stuff and care less about doing (or staying in) business.

The risk involved with DSM/DSL technology can be reduced in several areas:

• Making sure you build a good language and generator
• Adopting a supporting technology that is forgiving to the mistakes that you WILL make
• Tool and consulting support by an organization who have experience in this area
• Assigning tool-evaluating techie who understands that technology is there to support business, not for technology's sake
• Understanding the social and organizational changes that DSM/DSL technology will introduce in your organization and getting support for it
  

Vendors and tool comparisons

I've been pretty amazed (yep...understatement) of how some vendor-executed (fabricated is probably a better description) tool comparisons happed to end-up in tool evaluation reports, which in turn amazed me that these things ended up there, copy/pasted in the first place.

Food for thought: Vendor-executed tool comparisons are always subjective

Don't use a vendor provided tool comparison in your evaluation report. The fact that the vendor-executed tool comparison shows that vendor's tool scoring best in most (some vendors take it that far to score best in all...ghehe) categories, should ring a bell: Something fishy is probably going on.

It's easy to twist a tool comparison in your own advantage:
a) you lie (it's called marketing)
b) you base the competition's data on some old, no longer supported product version that no one really remembers
c) you take only those categories (and give them complicated names) that you score good in, and lie about the competition

It's not the vendors fault really. It is ,however, embarassing to see a tool comparison literally copy/pasted from a white paper or website end up in a tool evaluation report. Sure it saves time making the report, but the potential for losing a year or two in extra work due to your wrong choice or laziness in making the report is very much there.

In a bid to help domain-specific modeling tool evaluators, we added a MetaEdit+ feature list to our website. We did not feel our opinion about a competing tool should matter to you, hence we left the column "other tool" empty, for you fill out. Also did we not feel qualified to categorize our tool features as "best", "average" etc. so we just kept it to "supported" or not. Should you feel we missed some categories then we will be glad to add them there.

Business before Pleasure

With Model-based development based on domain-specific modeling languages getting more interest from businesses, I have noticed several times now that teams blindly decide to build their own DSM tool using freely available frameworks, like the one offered by Eclipse, only to realize a few weeks (or months) later that the effort this requires is more than they initially hoped for.

There are many facets involved with building your own MDD tool like providing the ability to define your own modeling languages and generators, defining and associating the visual representation to the defined language, defining tool behavior, providing the means to immediatley test your languages and generators while defining them simultaneously, sharing your languages, generators and models with others, possibly even on hetrogeneous platforms, providing integration with other development tools, supporting different DSM languages at the same time etc. Building your own DSM tool does not end with your first version of it.

It's highly unlikely for one that developers will get their first DSM language right the first time, or that this will be a good DSM language. Furthermore, it is very likely that even a good DSM language will need to change over time, which will have its effects on the models that have been created with it. Normally, defining a DSM mechanism requires developers to concentrate on both language definition and generator definition simultaneously. If those developers also need to concentrate on making sure there is reliable tool support for their continuously changing definitions, the effort becomes very complex, very time consuming and very costly.

In order to make DSM a success, developers need to put the goals of business before the pleasure and challenge of building their own DSM tool from scratch....which is what it comes down to, really, when using free frameworks.

At MetaCase, our vision is that developers should be allowed to focus on building good DSM languages and generators, where the environment helps them in doing so by making the effort convenient and transparent. Developers should not be bothered with the intricacies of creating tool support for their own languages and generators, a good environment automatically provides the tool support for them. Not just for the "using them" part, but also for the "defining them", "sharing them", "maintaining them" and "integrating them" parts.

You don't want to spend man-years in developing a tool that in the end will make you a lot faster just until it inevitably becomes obvious that you need to make a change to the language, generator or tool...........and you can start all over again. This may be nice for people that like to build stuff, just for the fun of building stuff, it completely offsets the benefits the DSM approach has for the business goals.

Thankfully, some people have realized this in time, before having wasted precious time on building from scratch:

“Modeling with MetaEdit+ was indeed quite convenient and a lot easier to accomplish than trying to achieve the same results with Eclipse GMF,”
Ulf Hesselbarth, SIEMENS Communications.

"MetaEdit+ provides convenient tool support for domain (meta-)modeling as well as for the definition of concrete instance data, which is simplified by a domain-specific graphical user interface. Easy to learn — easy to use!"
Cord Giese, Research Analyst, Delta Software Technology.

"MetaEdit+ is the most sophisticated DSM tool,"
Scott Ambler, Ambysoft

"Even as a beginner with MetaEdit+, I could define a domain-specific activity language in about six hours - design, testing and one failed trial included,"
Laurent Safa from Matsushita Electric Works, Ltd., Japan.

"MetaEdit+ was the most flexible tool, allowed us to define our own design syntax quickly, and make fast experiments while developing the method,"
David Narraway from Nokia.

Do you need a sexy DSM tool?

I got some feedback today from someone who had done some hands-on with MetaEdit+, his first comment was that he did not feel too good about the UI, it had a 90ies feel to him. His other comments were very positive though. Although we have seen a major improvement in the UI since the previous version I somehow understood what he meant. I took a look at Microsofts Visual Studio DSL tools tonight to get a feel for how a modeling environment can look when dressed to kill and oh boy..... the guys at MS certainly put in their best cosmetic skills in order to make me wet my pants.

For those interested, MS has an online lab where you can test the new DSL tools without having to install the monster, I hear it's about 900Mb and requires 3 machines ;) , so an online lab comes in handy. Try Googling for MSDN Virtual Labs and you'll likely find it. After some registrations and wrestling between Firefox and a dusty Internet Explorer I got access to the lab, wet my pants, and found my next barrier was my Finnish keyboard setting but luckily managed to solve this fairly soon.

After doing the excercise "Building a Domain-Specific Language Designer" (in English this means: Making a sexy looking DSL tool support a very simple DSL) I have to conclude that I can do the same exercise also with MetaEdit+ within one hour. I admit I do not get the sexy environment with its rounded, shaded toolbars but on the other hand with MetaEdit+ I do not have to import any pre-defined stuff, like ehr...the domain model (read: whole language definition) and its entire visual notation in order to be able to complete the exercise within one hour. A note to the people at the Microsoft DSL team: If you just import all this stuff...can you then still call it "Building a Domain-Specific Language Designer" as the exercise implies?? I think a title like "Opening a DSL project in Visual Studio Team System" would be more appropriate. The sexy environment hardly compensates for the fact that this takes an hour to do.