How DSLs can remove the bottleneck from the development team

In his book, The Goal, Eliyahu M. Goldratt presents a way to optimize a plant using his Theory of Constraints. This book lays out the concepts that later will inspire the agile methodologies, which is applying the Theory of Constraints to the development of software. The book The Phoenix Project relates the concepts explained in The Goal with IT and software development.

The gist of the approaches in these books is the following. To optimize a system (for example, a development organization) we must:

1. Identify the system’s bottleneck
2. Decide how to exploit the bottleneck (basically, make use at 100% of the resources that are part of the bottleneck)
3. Make sure everything else works in sync with the constraints.
4. Elevate the system bottleneck, e.g. adding more resources, repurpose other resources to help with the work at the bottleneck, etc)
5. If, in a previous step, a bottleneck has been broken, go back to step 1

In many organizations, the bottleneck is the development team. The common solutions to elevate them are:

• Hire more developers or bring in some consultants
• Outsources some development to external developers
• Make them more efficient (agile methodologies, CI/CD, training, etc)

However, there is another way: bypass them completely by going directly from spec to code without the intervention of the development team. This does not replace the development team, but frees them to tackle the work that only they can do,

Enter Domain Specific Languages…

Domain-Specific Languages (DSLs) help the company to completely bypass the dev team by allowing the users to create their business processes or rules themselves. A dev team still exists to create and maintain tools, but once the tool exists, the user is capable of designing and deploying by herself the workflows or rules she needs.

DSLs are like programming languages but aimed at the subject-matter expert. They can describe a compliance reports, data manipulations, business rules, etc., but they are designed to be understood by the expert themselves, allowing them to directly the specification of the software. After they are done and have tested their creation, the users can directly have the code generated (or run by an engine) and have it ready to use.

This approach saves time because the development team is not involved, there is less risk of having bugs or missunderstandings and the design happens at a much higher level of abstraction. This allows the subject-matter expert to reason in terms he is familiar with, and sometimes domain-validations can be included at design time, which find bugs before the code is even run.

Do you think domain-specific languages can be useful in your organization?