Here are comments related to snippets of your article:

1. "Developers like to develop" - this is true; however, developers have developed using a wide variety of programming languages and OCL (instrumental to the fulfillment of MDA) is another programming language (in fact its similar to the much aclaimed language smalltalk), and in the same way that Java didn't become a big deal until Java 2, OCL and UML (now at 2.0) are likely to now gain the same acceptance. Also, see my blog for a way for developers and architects to work in pairs in a version of Agile Modeling that I am professing is the missing link between modeling and programming collaboration.

2. "There is a fundamental distrust of code generation and a resistance to this type of abstraction" - isn't any 3rd GL (i.e., Java) an abstraction, or two, from 0s and 1s?? And, doesn't the entire J2EE array of APIs provide even more abstraction from code writting?? And, doesn't every IDE on the market today provide all types of functionality that helps write and refactor code?? Conclusion: If it wasn't for increasing abstractions from the 0s and 1s a CPU uses, we would be producing the same amount of 0s and 1s today as 30 years ago. The fact that we (developers) produce vastly greater amounts of machine code through the "abstract" languages and tools of today then we did before is what produces "productivity". At the point productivity ceases to increase, programming (wirtting code) becomes a commodity given to the lowest bidder.

3. "The developers write the meta-data that would normally be in stereotypes and/or tagged values right into their code. For many this bridges a semantic gap that is missing in the visual modeling paradigm" - whether you write meta-data in the code or in a model it only matters from a business standpoint not an engineering standpoint. What I mean by this is that business models far outlive the applications that fulfill the business's objective. Modeling the business domain, its processes, and transforming that into code provides the business with a much longer lived artifact than code. You can use XDoclet, Java 5 annotation, or an external transformation/mapping file (as with MDA), it doesn't matter, the fact is you are still using the meta-data to generate specific code. Also, as far as the idea of a "visual modeling paradigm", once you add the rich semantics into the visual elements of the model, you know have much more than pictures. You have a programmically rich artifact with much more power than just written code.

4. "Another thing that developers typically don't like about the MDA approach is the feeling of lack of control over what is generated" - in the case of a MDA tool like the open-source Andromda, what is generated is exactly what you specify in the templates, metafades, and specific cartridge descripter files used. All of which is under the complete control of whoever the busines decides, including developers. I am currently writting a cartridge for Andromda to generate specific applications using the Sprng Framework, including Spring's MVC implementation as well as to include DWR(AJAX) integrated with Spring. There is no restrictions to the way I decide for the code to be generated as I am the one creating the templates that produce the code.

The arguements about how MDA, CASE tools, CORBA, Meta-data, etc have not been embraced in the past is an indication of the future of MDA is, IMO, absurd. In order for MDA to succeed, there has had to be, and continues to be, numerous different technologies and methodologies to converge. MDA is in its infancy in terms of being a practical approach to software development. The fact is that MDA is highly dependent upon tools, and quite frankly, no tool of the past has had the power, functionality, vision, etc to truly meet the needs of MDA. That is changing as we speak, with virtually every major tool vendor, and the two leading OS IDEs (Eclipse and Netbeans), introducing new products, or projects, which include UML modeling, OCL, BPM, and MDA functionality all wrapped up into a compete high productivity tool.

Best regards,