Hi Ken,

I was perhaps trying to be provocative to make a serious point 🙂

Re:- "In my opinion, *less* code is almost always a good thing - assuming it reduces complexity, maintenance costs, defects. Regardless of which tier the code lives on."

- Sure, who would disagree?

The thrust of my observation, is that by definition imperative programming languages (such as C#) almost force programmers (or rather lure?) them into micro-managing data, and decision making in software.

Having components that automatically write the SQL code is fine, provided that is really what is useful.

I tend to find that so many problems that are a pain to write in C#, are so much easier solved in SQL, provided you follow the 'natural' 'flow' and 'grain' of information.

The 'right' solution to a problem can very often be missed as organisations/managers/developers can say "We don't need to pay attention to what goes on in SQL, as we have this wonderful code-writing tool that writes our code for us".

My fear of taking this approach is that you end up with (bloated and) busy middle-tiers whiring and grinding round and round, and simply killing the associated SQL box with a barage of requests. This drives up hardware and licensing costs ("we won't write the code properly, just throw more application servers at the problem. SQL box dying? Get another bigger box. Data center suddenly not got enough power? Move to another one." etc.)

Of course, sometimes line-item approaches are best / absolutely required. It all depends on the nature of the system.