Should you develop a DSL?

Thoughts on ´domain, business model and development maturity

The most important consideration is this: you should only develop custom tools and languages for that part of your software that is unique to your business, that drives your unique position in the market. It is crucial that your tools are as effective as they can be for this part of your software. Everything else should be treated as commodities, and you should rely on off-the-shelf tools and frameworks. To make this concrete: if you are not Amazon or Netflix, then computing infrastructure, deployment tools and databases are not something you want to develop specifically for company. However, if your USP is algorithms for digital therapeutics, then a domain specific language that helps you express this algorithms as effectively as possible is a great investment (see chapter 6 in this paper).

But there are more considerations regarding your domain, your business, and your development organization. Let’s look at each of them in turn.

A Suitable Domain

If your domain has one or more of the following characteristics, these are good signs for benefiting from a domain specific language.

Richness and Variety Is the domain suitably deep, does it have enough intricacies and variety? Is it timeless to some degree? Are there people who are experts in the domain, who have spent half a life understanding it? Is there a rich vocabulary and specific notations? Would non-trivial analyses be helpful to users?

Boilerplate and Fanout Some software platforms require a lot of boilerplate code to use them correctly. In other cases, lots of derived artifacts — such as documentation, design diagrams or coverage reports — are necessary to comply with a particular process. Both cases are excellent opportunities to describe things once, at a suitable level of abstraction, and then automatically generate code and documents.

Platform Independence Another driver for DSLs (and code generation) is the need to run the same domain logic on different platforms. Either in parallel (e.g., server and phone) or over time (e.g., your systems’ functionalities lives longer than the technology of the day), and you don’t want to reverse-engineer things over and over again.

A Suitable Business Model

Here are a couple of characteristics that benefit the usefulness of DSLs from the perspective of your business. One or more of them should apply to you.

A Medium-term Outlook A DSL is not rocket science, but it is an asset that will pay itself back over time. How long the amortization takes depends primarily on the increase in efficiency you gain from using the DSL vs. the investment for its development. But if your business focuses only on the current quarter then it’s hard to make it work.

Benefit from Effectivity If you are a solution provider and sell time, people or effort, then an increased effectiveness of your development effort might not be terribly useful. If you sell products and want to release on a shorter cycle, or if you develop systems internally and want to accelerate your business agility, a DSL might be a great investment

A Degree of Sameness Like a framework or a library, a DSL embodies a set of abstractions that you use all the time in your work: if each of your products or projects is in a different domain, it is harder to justify the development of a language for that domain — and you might also not have the deep experience. In contrast, if you develop digital therapeutics apps, satellites or payroll software all the time, then investing into making this more efficient is great!

The Development Organization

Finally, I have some thoughts regarding the development organization that might develop and/or use the DSL.

Technical Maturity Developing a DSL (and using it at the same time) requires a certain maturity in your internal development process: you’ll have to manage the requirements for the language, develop it incrementally, ensure quality and regularly release it to your users. If you and your teams struggle with build automation or unit testing, developing a DSL might be a jump too far. On the other hand, if you have done plaform- or framework-based development in the past, a DSL is a logical next step.

Willingness and Ability to Change A DSL moves the “threshold of formlization” earlier in the development process. This is likely a significant change in the process. It requires people to change, to learn new skills and to go through some temporary period of reduced productivity as they learn the new approach. The technical developers have to learn how to develop languages and gnerators, both skills that are not too widespread. Everybody needs to be on board to harvest the benefits of the approach.

Final Thoughts

All of these considerations are based on what’s on the decade of language development many with customers and various domains. Which of these criteria, do you think, are the hardest to meet in practice? The domain is usually not a problem. Most domains I have come across can benefit from DSLs. Not all of course. The biggest problem is usually (1) the medium term outlook, where companies are not willing to make an investment, and (2) the willingness and ability to change, where management wants to make the investment, but the organization resists.