DSLs Are Not For Muggles

The year is 1959 and Rear Admiral Grace Murray Hopper, better known as Amazing Grace, has just invented the Common Business-Oriented Language, better known as COBOL. ⊕ Most mainstream computer languages are for general-purpose programming. Exceptions include a category of mini-languages with more narrow and specific focuses. Such a mini-language gets called a Domain-Specific Language, or DSL for short. There are all sorts of DSLs focused on solving different problems. Some examples include query languages like SQL and GQL along with popular markup languages like HTML. One of its stated goals is to remain readable for non-technical staff.

I would never detract from Amazing Grace’s contributions. Therefore, I will focus on the particular hypothesis in which companies assert non-technical employees can and should be expected to solve problems using source code. Broadly, the answer is no, although the “dream” of non-developers working with code has refused to die.

In many cases, this dream of end-user programming has given birth to some of the coolest software tools around. Think of everything from business folks using spreadsheets to artists using processing. In fact, this continues today with the development of creative tools like programmatic music composition with Sonic Pi and authoring interactive fiction with Twine. Still need more in this direction of accessible software creation? Check out Decker!

But, this creative drive isn’t what I’m referring to. Rather, I refer to the workplace/industrial inclination to make non-developers author code. Perhaps, my favorite example of this going poorly is asking Product People to write Cucumber test scenarios. Back when I was a Rails dev, there was this dream of Product People writing Behavior-Driven Development (BDD) specs and passing them to developers to implement. In addition to treating developers as mere order-takers, this never worked.

The main reason that I saw this fail was that it was unreasonable to ask our non-technical Product Person to write solid Gherkin syntax. This resulted, primarily, in a lot of broken-by-default test cases and misspecified features.

It often went something like this:

1. Product Person enthusiastically writes a Cucumber feature file using their folk knowledge of Gherkin syntax.
2. Product Person sends their feature file to the dev team, who must spend time fixing it.
3. While rewriting the feature in valid Gherkin syntax (with supported steps), the dev team deviates from the Product Person’s true intent.
4. The dev team must then check the rewritten feature with the Product Person to iron out any problems they introduced.

This process involves a ton of waste. The real power here is in the conversation between the dev and product teams, which they should have had from the very beginning!

While I used to be anti-Cucumber because of my past experiences and biases, I later had some positive experiences with it. These made me see how Cucumber has valuable uses. I’ve used it successfully, but NEVER when asking a non-technical colleague to write code. Rather, I’ve found that Gherkin’s power has been in its literate nature and inherent readability.

In the example above, it would have been better if the dev and product teams spent 20 minutes having a conversation. During this, they could have worked together to co-author the feature file based on their shared understanding.

Again, the problem wasn’t Cucumber-as-a-tool, nor was it Gherkin-as-a-syntax. Fundamentally, it was about unfairly asking non-technical colleagues to write code.

To my knowledge, the early examples of non-technical folks who were tasked with writing COBOL became COBOL programmers Let’s never forget the foundational contributions to computing made by countless women whose original job title was “computer” . That’s probably because they needed to amass a rather large amount of specialized knowledge to be effective. Maybe because specifying things such that computers can “understand” them is really difficult. Seriously, there are multiple books and websites (and tools!) dedicated to the topic of unambiguous specification in various forms. All of them, are aimed at programmers.

Ostensibly this isn’t merely a matter of syntax, but also a matter of semantics. How would a non-technical person know to think about the corner cases and failure conditions which programmers are trained to consider? I might expect an expert in product to think about failed communication between a client and server. But, would I necessarily expect them to consider the specific cases of HTTP API request timeouts or high-latency connections between data centers?

So it’s entirely possible that a non-technical person becomes technical enough. Alternatively, they could just engage in collaboration with technical staff in ways which respect both of their professional specialties.

Truthfully, I love the idea of Domain-Specific Languages. The whole concept of moving the tool closer to the problem at hand is wonderful. We’ve all seen it work, too. There are examples ranging from NASA to Terraform to Rosette to GraphViz/DOT. Each of these successful projects serves to showcase the utility and effectivness of DSLs.

So let’s keep DSLs aimed at programmers, where they belong.

Special thanks to Amber Bartlett and Richard Feldman for fast feedback on earlier drafts.

← Back to All Posts