DSLs are relevant only to companies that build software by making developers and some kind of non-developers collaborate. This is the situation in which DSLs shine. If this is not your case then probably adopting a DSL should not be among your priorities.
- You build software for tax calculations. You have tax specialists collaborate with developers
- You build digital therapeutics software. You have healthcare practitioners collaborate with developers
- You build business automation software. You have business analysts collaborate with developers
- You build actuarial software. You have actuaries collaborate with developers
- You build software to control engineering processes. You have engineers collaborate with developers
There are no other single factors that make a huge difference. Regarding the size of your company, if you can afford to invest tens of thousands of dollars or euros to get the DSL designed and implemented for you, then you are not too small. The field you operate in is irrelevant: there are applications of DSLs in all sorts of verticals. I can just say several examples seem to work particularly well in regulated fields, probably because those companies hire many specialists.
Why should a CEO care about DSLs?
- There is a cost in making your specialists and your developers communicate. They spend a lot of time explaining what they do to each other and there are misunderstandings. DSLs can bring down those costs
- Because they can help specialists do their job more efficiently. Often specialists have limited tools to check their reasoning. Many errors are found only late in the process when developers start writing code. That is terribly inefficient. When we use DSLs we can give tools to specialists that help them do their own thing and find many errors themselves, early in the process
- Because it can reduce time to market. In each case we have ever seen, once you get a DSL people can do their own stuff more efficiently and more quickly. As a result, things take weeks instead of months and you can put your products out there much more quickly
Ok, what are DSLs?
In essence, think of super-smart editors that can help specialists write things down correctly.
Imagine these editors have a “reasoning spellchecker”, which points out errors.
And imagine these editors being able to generate automatically useful stuff: software, documentation, configuration files, and more.
No, there is no AI involved in the process. What makes it possible for these smart editors to be constructed are DSLs. The technology behind it is actually quite boring and reliable, but let’s keep that between you and me.
That’s great, but what could go wrong?
Now, there are challenges and risks when adopting DSLs:
- DSLs designers with the right skills are rare. You may need to wait to get the right people available to get started or to scale up your project. You do not need a ton of people for creating DSLs, but you need the right ones and you cannot find them that easily
- Adopting DSLs changes how things work. It does not matter that things are changed for the better, someone will be resistant to change. It could be the manager leading the testing department who all of a sudden needs fewer people, or it could be a long-time employee used to get things done in a certain way. In our experience, while people can consider themselves to be open to change, they are not always so ready to adapt their way of working, when needed
- Developers may be against DSLs if they are not involved right away in the discussion. DSLs make the life of developers easier, but they frequently misinterpret the idea behind DSLs, so they may think it is not possible to achieve what DSLs promise. It should be clear that DSLs are not about getting rid of developers. It is about removing the boring back-and-forth dance to implement, correct, and revise once more details in the code based on how specialists change their minds. This is done by making the specialists become much more independent. Developers will still be very important for the development of the core platform. Typically developers, in the end, see how DSLs benefit them too, but their concerns must be addressed by involving them properly, or they could resist and even sabotage the project
Ok, this seems to make sense. How can I learn more?
- You can throw some technical material to your CTO. For example, this guide.
- You can read some case studies, like this one: Voluntis Case Study
- And you can, of course, ask us to explain more, and more importantly discuss if and how this can work for your specific case. We could start with a 45 minutes call to discuss your case. You can book it by filling out this questionnaire. You can also write at [email protected]
If you are interested in this movement, you may also want to take a look at the Subject Matter First Manifesto
You can also find some resource here:
Some articles related to this topic: