Sadek Drobi’s Blog

Even the most successful project becomes a failure when a new technology comes out and everything has to be rewritten from the ground. This is why business logic has to be separated from technology. And, according to Kathleen Dollard, code generation is a promising approach to achieve it.

http://www.infoq.com/news/2007/12/code-generation-for-business

Separating business logic from user interface code was one of important lessons that legacy Visual Basic programs taught us. Kathleen Dollard actually argues that business logic should be separated from any technology to avoid rewriting everything when a new technology comes up. And, according to Kathleen, code is technology, thus business knowledge has to be isolated from it as well:

Combining business logic with any technology dooms it to be rewritten from the ground up when we get a new technology – and code is technology.

[…] You cannot combine code with business logic.

The shiniest, prettiest toys and languages are tomorrow’s legacy.

Business knowledge should rather be stored “in the places it resides: database structure, service contracts, test definitions, logic rules, workflow, business object code, validation rules, authorization guidelines, user interfaces, etc.” One could argue, however, that whatever the place we choose to isolate business information, it is still based on a technology that cannot escape change. Nevertheless, there is one key difference between using code “as core way of expressing intent” and storing expressions of the intent with a given syntax:

You can recognize, categorize and morph declarations. Sure, the syntax of any declaration is based on the technology its intended for. […] But, any metadata worth its salt can be transformed into any other metadata syntax.

[…] By separating out the known aspects of the job we’re doing – we can use it or not use it in the next great thing.

This way, Kathleen advocates for code generation as a means for extracting and separating business logic from code. Based on her experience, she argues that “even the best normal development efforts are worse than mediocre code generation development”. The most professional team using agile methodologies can succeed in delivering quality software on time, but in the eyes of Kathleen Dollard, this would still be a failure because “the whole thing will start over with a new technology.”

It is important to highlight that in a generated system, code still plays a critical role. Inability to map bugs was one of the reasons of the 4GL disasters in the eighties. Generated code allows avoiding this pitfall, because it is actually “how the system tells you what it’s doing”, which is absolutely crucial for debugging. Hence, Kathleen describes code as “the necessary evil” and argues that it should be treated as such.

She emphasizes that such approach requires a fundamental shift in the way we conceive programming, significant leadership as well as appropriate tools that would allow doing code generation well. Kathleen argues that today, “.NET is not an inoculation protecting your project from technology change”. It actually speeds up its pace. However, there are already some premises for a more widespread use of code generation.

On could mention the entity framework for mapping to metadata and XML literals which have, according to Kathleen Dollard, “amazing possibilities for code generation” and the potential to “unseat XSLT for complex generation.” Kathleen expects the area of code generation to be very dynamic in the following years. This should get us closer to proper development which, she believes, would be based on “a combination of code generation for all the stuff its dumb for us to write married to a highly morphed BDD for all the code we do have to write.”