Throwing a DSL over the wall

time to read 3 min | 407 words

Here are a few thoughts about the idea that given a DSL, you can just turn your entire business related stuff to the business users, and be done with it. This kind of thinking is very common, from the dreams of the secretary building applicaitons by dragging boxes to the business analyst modifying the workflows.

I disagree with this quite strongly. Giving a user this type of tool is an irresponsible step at best. The users are not developers, and they will make mistakes. And the first time that the business will lose money over it, it will be your fault.

  • It will be your fault when the server is on 100% CPU because the user has created endless loop.
  • It will be your fault when the server is down because of stack overflow.
  • It will be your fault that Mike from accounting made "just a tiny modification" that suddenly means that you sold a product with for 50% less than you paid for it.
  • It will be you fault that Joe just got a paycheck proudly stating -43.9.
  • It will be your fault that the company baught the entire fish market for the next three years.
  • It will be your fault that no one has any idea what the company's own business processes are.
  • It will be your fault that the database contains incosistent data.
  • It will be your fault that there is not control over it.
  • It will be your fault that there hasn't been an audit log for the last three months.

It will be your fault

Handing a user a tool like that is wonderful, it is a tool that can enable better communication and rapid response betweenthe IT and the business. Having a DSL means that you are talking in the same language, that you are less likely to mess up because of translation problems.

It does not mean that you can just throw it over the wall and walk away. A DSL is code, and like all code, it requires code review, QA, change management (source control), testing, intention revealing semantics, perf testing, auditing, error handling, transaction handling and much more.

Professional developers are having problems with handling that, giving it to unexperienced users is a mistake. It might work for the first few, but this is not a sustainable approach.

Consider the departmental application and their usual bar of quality. Do you truly intend to bring that, knowingly, into your codebase?