I went with my team of developers to RobotsConf 2013, which was put on by the same organizers of JSConf. After a night of hacking, my team had produced a failed Robot-Controlled hot air balloon (there was a physics miscalculation). The failure was so spectacular, that I was asked to relate our experience to all the conference attendees at the end of the conference. When the call-for-papers went out for JSConf 2014, I decided to submit a talk, though self-submissions were discouraged in favor of speaker suggestions from the attendees. I chose to speak on a topic that I thought was interesting, and submitted it with a note of, “I’m the guy who spoke about the hot-air balloon at the end of RobotsConf”.
I waited 2 months, leading me to the conclusion that I had been rejected, and then got the notice that I was accepted. Apparently, I was one of over 600 submissions, and probably one of the few self-submissions, so I was lucky to get in. To my surprise, I was the first talk of the conference, which made me a defacto keynote speaker of sorts. One of the conference organizers later confided that he thought mine was one of the better talks, which the number of view on YouTube later confirmed, as it put me at the 3rd most viewed talk of the conference.
One of the nicest outcomes of the talk was that Rafael Corral took the content of my talk and wrote a more sophisticated version of my DSL. That was a very nice surprise indeed. There was also a cool experience when one of my colleagues at work exclaiming “Neil made it to the top of Hacker News!”, which was only partially correct, as I was only one of a list that had made it to the top of HackerNews.
When writing complex business logic, it is critically important to maintain clean code though the judicious applications of Test Driven Development and Domain Driven Design. However, even these powerful techniques fall short of solving the problem at the heart of building complex software: building what the customer actually wants.
Domain Specific Languages (DSLs) allow us to capture complex business requirements in code written in the language of the customer. Once an ubiquitous language between you and your customer is defined and implemented as a DSL, the code can quite literally be given back to the customer to edit and refine. This is not a theory, or a myth. I have done this under real-world constraints and deadlines, and you can as well.