Code generation: Good, bad or ugly

I have just completed an evaluation of a .NET tool. This was planned to be a review of the tool in question but I have managed to get sidetracked by what is one of the biggest debates amongst software developers. After all real developers write code – they don’t generate it. Some take this to the extreme and won’t even use third party tools or components; after all we are paid to develop software why should we pay to use someone else’s.

Of course that’s in the Microsoft world. Step out into Ruby on Rails land and the answer is more likely to be why wouldn't you! Java developers have a ream of frameworks to choose from and massive productivity gains to show for their efforts. Even PHP developers have some very good frameworks to get their applications off to a flying start – and don’t think I’m knocking PHP - I use it regularly. Technical Purism vs Commercial Reality I first started thinking about this in a debate on the merits of Java vs C++ at a developer conference way back in the 90s. One of the strongest arguments from the C++ group was that automatic garbage collection is a bad thing because it leads to a lack of discipline amongst programmers. Of course the debatees were all academics or authors. they made their living out of teaching development but none of them had any need to deliver commercial solutions. And today they have had to come to terms with automatic garbage collection as a standard – they have even had to deal with the fact that the modern generation doesn’t need to understand pointers!!! The bad We lose control of the code Actually no. Most modern systems are template based and you have the ability to either modify these templates or create your own. Obviously it does depend on the tool you choose and you need to do your homework up front. What if we need to change the code Pretty much as above. Since we are talking .NET the tool should at very least provide partial classes which will not get overwritten when you regenerate your code. It is important that the development team understands the templates and knows how to change these. If you don’t like the way something is generated change the template. This is infinitely preferable to changing hundreds of instances in source every time you have to re-generate. There is no documentation Back to doing your homework up front. Some systems are better than others on this. Certainly if they are template based there should be ample source code comments – and if necessary you can modify the templates. There is an awful lot of code Well yes – but you’re not writing it, maintaining it or debugging it. Today system resources are regarded as consumables (memory, processors, disk space etc). Modern software design is more concerned with supportability, maintainability and extensibility than raw code efficiency or memory footprint. How many people put business logic directly in their user interface layer because it is faster. (Please don’t answer!!!) The good The business case Development teams cost money and are (usually) highly skilled. Do you want them to be writing frameworks, spending hours on repetitive tasks such as CRUD (Create, Read, Update, Delete) or would you rather they spent all of their time adding value. So you have a single agile team of 7 plus a Scrum Master and a Product Owner (Well I am a scrum guy). On average these each cost you £500 per day. You have 40 entities and producing the CRUD procedures each takes one very ambitious mythical day. 40 days x 9 x £500 = £180 000. Well that’s a pretty convincing business case right there – and we haven’t even touched on the data access mechanism or application framework. Pre tested code If the templates have been comprehensively tested the generated code will be consistently good. It won’t fail to compile because the developer made a typo. It won’t forget an important step because it mind was otherwise occupied. Most modern generators will even generate your unit tests for you – make sure this is the case as part of your homework. Better design needn’t cost more One of the agile values is simplicity: Do what is required – nothing more and nothing less. Coding for today without thinking about tomorrow is a great way of getting something done quickly. What if the requirement was a simple desktop application and you opted for a monolithic architecture (it happens). A year down the line the organisation has been really successful and decide to deploy the solution as a cloud application. Time for a full re-write. Not necessarily. Using code generation means that it need take you know longer to provide a properly architected solution. I’m not necessarily suggesting that you would go with a full blown enterprise architecture for a 5 user desktop system but you do have the option – and of course you could regenerate using different templates, or additional features of the same templates in the future; without losing your customisations. Consistency in design This won’t be affected by the personal preferences of individual developers. The ugly Just thought it would look good in the title… Considerations for choosing generation tools

• Cost – it’s a commercial world we live in
• Documentation – how much is there?
• Support response
• Availability of third party or add-on templates
• Support for appropriate industry standard architectures
• Do we have access to the templates for customisation or to create our own
• Interoperability with existing toolsets. If your developers are using Visual Studio you wouldn’t want to use a tool that requires you to use its own IDE and creates projects that can’t be loaded into Visual Studio. Similarly if you are using nUnit for unit testing you wouldn’t want to use a tool that generates tests exclusively for an expensive proprietary system.
• Run time costs: this may not be an issue if you are developing an internal system but do be aware of any required server component or environments if your software will be widely deployed – and make sure you understand the licensing implications.
• Open or closed source: your call, if choosing open source your decision and chosen option needs to be thoroughly reviewed. Commercial organisations may have a stronger incentive to keep the product, and its documentation current.