If I hear it one more time

"Why don't we use code generation"...

I'm going to put it very very simply.. I HATE CODE GENERATION.

Why? It's simple. Code generation CAN help developers get applications to market quicker. I won't argue that point at all. My argument against code generation is all about abstraction and workflow.

Abstraction
I've worked in many environments, but one thing seems to remain the same. At some point, you will have to integrate with an older system. More often than not, that integration will be done at the database. Yes, I know the whole point of SOA is to re-use the services, but how many places are in a position to do that yet?

Anyway, back to the point. Over the life time of an application, entities in a system tend to change. They acquire new attributes, they change their behaviour and many other subtle changes. The end result, a person for example is could originally be stored with just an Id, a few fields for their name and maybe a data of birth. Over time, more information gets added. The person may now be an Employer, an Employee, a Client.

As these entities gain more attributes and new meaning, business rules will be applied to each different incarnation. A person is no longer a person.

Now you may think I've gone off track a little. What does this have to do with code generation. It actually has 2 things.

The first is that Code Generator Fanatics will just point their favorite tool at the database and let it do all the work. The problem, is that you now have services and a UI that are just a representation of a person with lots of other information. This is how you end up with applications with 20 tabs and a few hundred fields that all need to be populated before the user can press save. It's hideous and not very user friendly.

The second part is to do with the "We can just rebuild the whole thing" mentality. In this world of source control, managed change etc, at what point did it become acceptable to just blow away half a project and re-generate it just to add an extra field to an entity. Ooops.. Did someone change that file..

Workflow
Next up on my list of gripes is to do with workflow. I touched upon it just above. I'm a big fan of services guiding workflow. I don't know how often I end up on a project where the services are just a set of GetXX(), AddXX(), UpdateXX() DeleteXX() methods. I hear developers talking about CRUD (you know, create, read, update, delete).. This stuff works fine in small projects, but when you start having to add workflow into the picture, it very quickly becomes messy.

Lets look at a simple problem with this. Imagine that within the database we have Users and Contacts. Both a user and Contact have Addresses. Some smart cookie along the way realised that this could be normalised and they both have a relationship with the same "Address" table. Now you need a SaveAddress() method. That's cool and all, but should you be saving an address without some sort of context as to why it exists.

In this situation, I tend to go for AddAddressToContact(Contact, Address), AddAddressToUser(User, Address). This is clear what is happening and you no longer have confusion about why your wonderful OO design doesn't work in a messaging environment.

One Final word
I'll also throw in another little issue I have, and that is when devs take it just that little extra step. They also code gen their unit tests. C'mon... What point are unit tests if they are always going to succeed. You are making our unit tests so they only call your code the way YOU WANT OUR CODE TO BE CALLED. It's not testing for the unusual cases.. Unit tests are supposed to test the unusual cases as well..

Anyway, that's my little rant for now. Feel free to drop a comment about how wrong I am on the subject and I'll buy you a beer while I argue with you until I'm blue in the face :)