What the biggest risk in development (leaving out frightening common omission of unit testing)? That what is written down as requirements suffers a chinese-whispers style path to code. TDD was an approach to address that risk, by saying that before functional coding starts as test based on requirement is derived, then functional coding done to pass the test. Oversimplifying the nuts and bolts, but that is general idea.
On the back of TDD (and other *DD’s), tools have evolved based on this principle, and seeking to further smooth the requirements -> code process. Domain-specific languages have been around for a while now (SQL is one earlier example), and part of the evolution of programming in general. Programming languages are becoming increasingly more readable – and for good reason. Essentially, code and natural language are meeting the the middle. It is important to remember that DSL is limited by nature, aimed as it is at solving particular problems.
One of the more interesting of the DSL family (from Agile management perspective) is Language/Grammar Oriented Programming. The idea is to take the user stories/scenarios, and then to try to create an implementation language as mapped as possible to the user’s descriptions. Not straightforward, and concessions have to be made on both sides to ensure a unified approach. The future of code, is that it will make sense to anyone looking at it. Most languages have elements of readability – in fact if you examine any code, you will instantly see discernible data, instructions and conditions.
In BDD, the most given DSL style would be Grammar-oriented programming (GOP) and Grammar-oriented Object Design (GOOD). These are ideal for designing DSL for a specific business domain. GOOD is a method for creating and maintaining dynamically reconfigurable software architectures driven by business-process architectures. The business compiler was used to capture business processes within real-time workshops for various lines of business and create an executable simulation of the processes used.
Instead of using one DSL for the entire programming activity, GOOD suggests the combination of defining domain-specific behavioral semantics in conjunction with the use of more traditional, general purpose programming languages. GOOD incorporaties DSLs from a given business domain (BDSLs) in order to provide a seamless transition from business requirements through to component-based software architectures. By extending modeling techniques to include a domain-specific business language, i.e., using user story/scenario format.
Will be writing a lot more in this area, as it ties in nicely to my current interests in ATDD (both in terms of processes and tools).
Related posts:
