Summary: can we figure out if a DSL is the right choice for a company, limiting their investment in this assessment?
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:
- 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?
- Understand the problems they are facing. This is hard, because people became blind to their problems when they have them long enough.
- Understand the different roles and their specific goals
- Understand the processes
- Understand all sort of tools they use: excel spreadsheet, Python scripts, classical software development, modeling, tools to analyze requirements
- 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