I’ve known about DSLs for a while, but a very interesting presentation by Neal Ford at the TSSJS in Prague last year made me reconsider the subject. Before, I considered DSLs were applicable only in very specific situations, like where there existed a huge number of requirements that were expressed very formally. Think rocket launching for example.

But now I tend to think that in most situations, there exist requirements or business rules that could be captured more easily than by writing sentences in a requirements document, then writing more detailed sentences in a specifications document, then writing test cases to make sure the requirements are fulfilled, then implementing the logic in code. And then of course doing it all over again when the business rules change.

If we could express these business rules in a way that could either be interpreted at run-time, or be compiled into the software, we could skip all the chain. We wouldn’t need to validate the software’s behaviour (regarding these requirements) against specifically written test cases, because the integration mechanism  of those business rules would have been validated. In other words, if the software doesn’t behave as expected, it’s not because of a bad implementation, it’s because of a bad business rule.

I once worked with a company named ItemField (which is now part of Informatica) that had a technology (ContentMaster) to transform almost any kind of document (mostly Office documents, PDF and such) into XML, and vice versa. They had thought of extraordinary ways to use their technology; for example, by building an appropriate transformer, they could turn a formal specifications document into a parser for the format described by the spec. If that sounds esoteric, consider the specifications for SWIFT messages, also known as ISO-15022: it’s a huge collection of rules that define different kinds of messages, and how they can be constructed. Now imagine having to write a parser for all the message types… it would be a nightmare to code by hand and test because there are so many rules to implement! (Some have tried: see project WIFE – still a work in progress). Well, ItemField had written a transformation that generated XML parsers and serializers for SWIFT messages right from the specification! So if anything changed in the spec, they just had to run their transformation on the new spec, and that would generate new parsers and serializers. They called it specification-driven transformation.

Apparently ContentMaster was included into Informatica’s portfolio as part of their B2B Data Exchange product family, but I don’t know what survived of the specification-driven transformation.

Anyway, the idea behind this approach is dazzingly powerful: use business rules exactly as they are formalized . Don’t rewrite them N times using a different formalism, creating N possibilities for things to be misinterpreted by a human. For example, we know many domain specialists would write rules in Excel; given a technology such as ItemField’s, it is usually possible to parse these rules directly from the Excel sheet (provided they are reasonably consistently written), and generate whatever is necessary to incorporate them into the software. If rules change, the domain specialists update the Excel sheet, we run the transformation again, and that’s it. Once we are confident that the transformation works (and this means that it has been thoroughly tested!), we know that anything wrong with the business rules comes from the rules themselves, not from the code.

I think this is where we’re heading, generally speaking: giving more control to non-IT people over software, by shortening the way between their expectations and the software they use. MDD is part of this trend, because models are more likely to be understood and driven by users than programming concepts. If we take abstract models as a kind of formal specifications (which they are), then what applies to Excel sheets could also apply here, provided that we can automate and shorten the path from model to final software. This is not the easy part, I admit.

Agile methods of course are also part of this trend, in a different way, because they involve stakeholders very closely and often in the process, and also aim at shortening the path from specifcation to software. For example, in Scrum the product backlog plays the role of master requirements, and while it still has to be written by hand, it is the only artefact between users and the development team.

I think we’ll see this trend amplify over the next years. It might feel like this will ultimatley mean less work for IT people, I don’t believe it. But that might just be wishful thinking.