A process to figure out if a company need a DSL

Domain Specific Languages
1

Summary: can we figure out if a DSL is the right choice for a company, limiting their investment in this assessment?

Current process

Currently if someone is interested in building a DSL and contact me, the best process I can offer is having 1 or 2 conversations online then setup a 2 days workshop at their place, with as many stakeholder as they can group. At the workshop I try understanding what they do, how they do it (their organization and their processes), and what problems they have. I then show some demo, we use whiteboards a lot, I listen as much as I can, then I build something super-simple in the last half-day and we end the workshop. Following the workshop we conclude it makes sense to build the DSL and move forward.

Problem with current process

Now, the thing I do not like about this is that at that stage the client suspects a DSL could be useful but they are not sure. So it is expensive to coordinate a physical workshop, including several of their key persons clearing their agenda for as much as possible during those 2 days. Then pay for the travel expenses and my fee. Deciding to do this investment when the possible answer is “you should not get a DSL” is perceived as a risk.

Need for another process

So I wonder, would it be possible to come up with a process that is cheaper in terms of organization effort and money for the client? The outcome of the process should be an answer to the question “Would it make sense for us to build a DSL?”. Either the answer is no, and then they got to that answer with a little investment, or the answer is yes, and at that point they have more confidence to justify larger investments.

Reasoning on this new process

I am trying to reflect on an approach for this.

I am reflecting on several aspects of this:

  • What should we know to decide if a DSL makes sense?
  • Who should we talk to?
  • How can we get the relevant information with a reduced effort on the client side?
  • What would be convincing enough to justify moving forward? My opinion? Some demo? A prototype?

Currently I am thinking that we should:

  1. Understand very well what they do and what are the crucial metrics in what they do. Is it time to market? Is it the cost of development? Is it the number of bugs?
  2. Understand the problems they are facing. This is hard, because people became blind to their problems when they have them long enough.
  3. Understand the different roles and their specific goals
  4. Understand the processes
  5. Understand all sort of tools they use: excel spreadsheet, Python scripts, classical software development, modeling, tools to analyze requirements
  6. Understand their technical maturity: do they use tests? Do they use git? Do they have build servers?

There is an overlap between points 1 and 2, but in point 1 we identify metrics that are important, and are currently not a problem. They should stay in that way.

I think I should define better what I need to learn to give them an advice regarding building or not building a DSL, and the rest will derive from this. So I have just started reflecting on this but I was eager to hear what you are thinking :smiley:

1 Like
2

Well, cost effective from staff efforts is OK-ish but money … no way! The person who give green light for that 2 days expenses already put that money as a loss…it’s a trial, a “let’s see if that thing could deliver” so do not set a goal in the new process to reduce that particular costs.

1 Like
3

Some random ideas

I would add a double SWOT analysis one for DSL the customer might need and second one for a “classical” language like Kotlin/Scala/Java/Python/etc

Even the customers chose not to pursue DSL road, you should be able to sell them something (professional services, consultancy etc)

managers are scared to go with DSL because they are not sure if a young employee will accept to learn and use that language or they cannot hire a coder, should be trained in house.

or DSL the ecosystem is narrow, am i right?

maybe managers think that in 5 years you will be out of business and why should handle such a problem?

you should understand what concerns do they express during meetings, conversations and lunches and try to mitigate them

1 Like
4

Based on my experience there are several variables in the decision making process and (far too) many of those are non-technical. Together with some customers we tried to describe some of them in a book chapter (www.dsmbook.com). In the dsl-course by @mbarash they are nicely summarized in http://dsl-course.org/dsl-development/ on “Organizing for DSL Development” and “Template for DSL workshop”.

3 Likes
5

Exactly, the first thought when any customer thinks of such a transformation, money should not be an issue (almost never interacted with any customers btw; always been into R&D rather maintenance). Also the number of bugs is way similar. Problems may not manifest in number. It may become harder to solve. Reasoning based on what I heard on debugging harder memory issues with Java and Go language (I have not worked on them). Would like to quote what Stroustrup has said: “C makes it easy to shoot …; C++ makes it harder, but when you do it blows …”. Atleast with C, guarantee to debug the harder is feasibly fast, when the code size reaches relatively astronomical, is more, not to speak of performance wrt scalability. Sure, I have not understood DSLs yet.

May be the latest technologies take this point already and offer better tools. But still I lean to believe not, for the sheer amount of abstractions they introduce and the breadth of each layer are akin to inputs for Ackermann function. Unless any mathematically modeled research which proves otherwise, keep the doubt.

So the only reasonable thing is first and/or fast to market.

I hope reviving this thread is fine, and I am not sure if there is any policy to start a new thread by referring this thread if the actual thread is becoming a bit older.

6

Just remembered this article:

http://www.paulgraham.com/avg.html

Enabling first to market. If they are already doing it, they may not need a DSL.