Charles Pockert (10/6/2010)
I think the Indy 500 analogy is flawed in that not all cars on the road are trying to win the Indy 500...
Many people are making the same statements and I'll just add mine.
What the author, David Ziffer, is proposing is a good idea in a sense and something that framework developers have been trying to tackle for years. It is not trivial, mainly because the problem keeps changing.
Like Charles said, if you confine development to a strict set of rules and a very limited set of user cases, like the Indy 500, then it would be very easy to churn out generated code based on a set of features and requirements. In fact, if it was that easy, we'd have a system that already does that dynamically. Just enter your list of fields, their constraints, and roles/permissions and click "Go". Honda practically does this already, they just haven't entirely taken out the human element yet and replaced it all with robots.
However, not only does the domain have practically unlimited user scenarios (including the ones we didn't realize in the first place) but the domain itself is always changing. Churning code has it's place, and leads to Go Daddy $1.99 websites. They are Ok for small businesses who like getting a stable and semi-dynamic website for cheap but it will look just like their competitors with no added value or "new" features.
In the last 5 years we've seen the development and wide-spread implementation of AJAX, REST, OData, WCF, Web Services, cloud services, hosted solutions, etc. While all of these were in some form of implementation before that it is only in the last few years that they have become mainstream and somewhat "required" for any apps developed today. This wouldn't have happened, nor would it be possible to produce, using rapid development/generated code.
I think generation of tried and true practices for specific domains of an application are definitely warranted. Why should a developer have to "design" the primary key structure of a standard Customer's table anymore? Churn out the 20% that is static, but I haven't found in my last few years of development that I can "outsource" more than 20% of my design like this. 60% still goes into designing the features to to work together in a quality efficient manner and the last %20 percent goes into the things I find that we never expected.