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.