The idea of building applications by first modeling them, then transforming these models into implementation code has been around for many years. Providing a higher level abstraction for defining software would seem to be a natural evolution. Twenty or so years ago, structured programming languages replaced assembly language, or machine code, as the most popular way to write software. About 10 years ago, object-oriented programming languages became entrenched as the most predominant languages, again raising the abstraction level. Lately, there's been a lot of talk about model-driven development as the next higher level abstraction.

Each step in the evolution of software development has been accompanied by skepticism, and model-driven development is no different. The skepticism is usually the result of overly grandiose visions and promises, opening up the visionaries to attack from the more practical types. Many programmers think that class diagrams might be helpful to document their designs, but they know that implementing complex systems by simply "transforming a picture" is a pipe dream. They know that all the expressive power of a programming language can't be available in a model because if it was, it wouldn't be any simpler (higher level). It would just be another programming language.

That said, most programmers do recognize that generating some of the code that they write over and over must be possible. How many copy-and-paste operations do you need to do before you start to wonder if there couldn't be a way of specifying parameters for patterns that you want, and just have the code generated automatically? Clearly, these patterns must represent some higher level abstraction that, if only it could be specified (modeled), could enable us to write a lot less code.