Generic Vs. Generated Code

Most IT applications encounter the same challenges - whether its how to implement the best user experience or how to make the application as flexible as possible - these question will raise in every enterprise web application.
Than the only question on stand is - how to implement this?

A couple weeks ago I started a new job.
The first few weeks of a new job - to my opinion - are the most effective if you want to open your mind to new\different implementations - after all there is no one answer for any of these questions - each has its pro's and con's.

But I'd like to focus on one very basic difference between many of the existing solutions out there: should my framework be based on generic code that will know to handle a variety of scenarios and systems, or a set of wizards and code generators?

Why Should I Choose Code Generation?
1. Time: Yep, you can lower you eye-brow and think about it - how much lines of code are there in a framework like NHibernate, and how much are there in Wilson's OR Mapper?
Its not that I'm judging Wilson's complexity, on the contrary - although the time it takes to get a stable beta for a complex code generator is less the half the time it takes writing a generic code, in most cases it will support the same amount of scenarios and maybe even have more features (because it can enjoy the advantages of strongly-typed code).

2. Performance: Because of the nature of generic code, it must support a variety of scenarios, objects, context etc. - hence it will parse configuration files, load assemblies, use reflection, and many other performance killers, whereas when working with code generation, the code generated is designed for the specific page\scenario\object and will use no reflection or type casting whatsoever.

3. Debugging: When I first started using NHibernate, it was on one of the early betas (version 0.7 I think...), needles to say it was very unstable, but the most annoying thing was when I got an exception while using it - to start debug it and understand the cause of the bug took me a couple of hours since I needed to understand the "black-box" code.
In code-gen, the code is as simple as it gets which makes reading it a lot easier.

4. Ease Of Use: Drag N' Drop your entities, check the "Lazy-Loading" check-box, and vuala you've got yourself a fully featured DAL. no config file wars, no xml-schema lookups no tutorials to read.
Simply put - you need to no nothing (is it really an advantage?).
The amount time it takes to teach your users how to use a code-gen wizard is usually less the time it takes them to understand the xml structure of the "black-box" config file.

There are several more pro's to code-generation, and yet still they are usually not taken seriously, why?

There are several reasons, but to sum it all to 3 words: S - O - C. Separation Of Concerns.

In its nature, generated code is not stand-alone, it doesn't matter if it's in separate classes, files or even projects (though it might be enough in some cases), it is still strongly-coupled with your code, hence a change in your code will result in re-generational.

But this is the best-case scenario, think of a bug found in production, you have to re-compile the whole application because of a bug in your framework! whereas in "black-box" (generic code), you simply replace the framework assemblies (with care!).

Conclusion:
It's true, code-generation is sexier (I cant believe I say that!!!), but in real world (enterprise) applications, it's simply too risky.