Creating Your Own Domain Specific Language For Fun And Profit

Language is that which brings us together, but it can often be that which divides us as well. Human language is often inexact, which can lead to serious issues when it is used to try and define complex business requirements. Studies have shown that issues from misunderstanding requirements are often the most costly to fix and can even undermine entire projects. How can we prevent this from happening to us?

In this presentation I will talk about how I was faced with an extremely complex business scenario ten years ago in a customer-facing insurance website; a set of intricate requirements about insurance coverages for property and auto policies that had to account for differing laws across all 50 US states as well as different types of policy and policyholder. Historically this had accounted for almost 75% of all defects within this application. To solve this we decided to use a Domain Specific Language (DSL). Working together with the business we created an unambiguous language for the requirements that was specific enough for us to automate the process of turning it into rules-format code that we could use within our application. As a result we were able to reduce the number of defects caused by this area to almost 0%.

That was ten years ago. How would we solve this problem today? What new tools are available to help bridge the gap between desire and results? In this talk I will try to answer those questions. I’ll also talk about how to develop a business case for using a DSL and collaboration techniques to help create the common language. Hopefully you will leave this talk with some powerful new tools for the next time you find yourself spending more time explaining what you want than building it.