The first Eclipse Acceleo Day took place last week and was a pretty nice event., no doubt we'll organize others like that :)
The day started with business feedback about Acceleo deployement and Model Driven approaches in IT units, more especially Cap Gemini, Atos Origin, Orange Labs and Bull. These big IT companies used different approaches to get a higher software quality, quicker, and even more important : easing the maintenance. Each of those approache was valid and was meeting their final goal and Acceleo was a big asset which is really nice to hear when you're part of that team :)
Slides will be available on the event program page.
I really can't summarize all the discussions and presentations in a single post, have a look on Goulwen's report which is way more detailled, but there is one feedback which need to be emphasized : Model Driven Software Development might sound like a big "corporate" expression quite far from the developers actual concerns which is about agility and quality, but it is not.
Using models and leveraging them with code generation techniques is just about that : bringing agility to your development process. With tools like Acceleo which are fully integrated in the Eclipse IDE, the developer has the power to build software systems quicker and better. What we've seen is that most companies are organized in "one transversal team creating the modeling environment and the corresponding generation templates", thats a common organization when a company want's to capitalize over its tooling and templates.
Keep in mind one thing : we are building tools which are making the task of creating of such a modeling environment (modelers, code generators or transformers) so easy, that a developer is able to do it quickly, even just for a single project. You might have a big boost of productivity, quality and consistency on your code just defining a small set of generator templates perfectly tailored to what you want.
So people claiming that Model Driven Development is incompatible with Agile Development are just plain wrong, the tooling supports this kind of development and make it easier, it will just depend on the organization you pick : if your goal is about defining a process for your whole group so that you get quality and consistency over all your projects, then go ahead with the transversal team and keep in mind you'll have to work on your tooling a lot more to handle all the projects use cases. If you just want to build a given software quicker and better, consider defining a tooling in a few days as it will make your life, as a developper, way easier.