Looking back on twenty years of software development, I think I must have spent most of that time on trying to improve both the quality and productivity of software development. Ever since I started to write small civil engineering calculation programs in Turbo Pascal way back in 1988 I got interested in writing better software faster. So right after I finished the second of fourteen programs in total, I started working on my first framework. It took some effort, but writing the other twelve only costed me less time than bulding the first two. Darkening perspectives There are good reasons for wanting to increase both productivity and quality of software development. First of all, if we may believe Gartner, we will have to increase productivity by a hundred-fold to meet up with current demands for software. That’s not going to be easy. Furthermore, technology is becoming increasingly complex. Only ten years ago, I was able to work both in projects using Microsoft technlogy as well as projects that were build on Java technology. Nowadays, I’ve let go of the idea that I still have an overview of either one of them. It is hard enough being able to work with some of the frameworks. A Silverlight expert is not likely knowledgable on NHibernate. Being able to work with Spring does not guarantee foxy user interfaces. Despite this darkening perspectice, there’s techniques and technologies that might keep you from drowning, by simply raising the level of abstraction of software development. Good frameworks do this. And, of course Smart use cases do that. Modeling in UML might even do so. And then there’s model driven development, or model driven architecture, or model driven engineering or domain specific languages. Different terms that all try to use the same means to the try to raise the level of abstraction in software development: generating code and sometimes even other deliverables from a model. What model? Well, any model might do the trick to be honest. Business process models, use case models, user interface models, domain models, and last but not least data models. DIY I think it was about eight years ago that I was helping a customer – a chain of DIY shops - set up a domain model for a help desk application, and after that build the application in .NET. Having modeled all classes, their properties and their services, I was typing over the same classes, properties and services in C#. So, as any decent developer would do :-) I wrote a code generator. That helped. Although empirical, I suspect that most code generation efforts have a similar DIY start up history. That’s probably why there’s so many approaches to generating code. Some of them really high-brow approaches that try to squeeze everything and the kitchen sink into the model and then try to generate the whole application, from front end to back end. Others really at the low and of the spectrum, making an effort re-engineering the database and generation create-read-update-delete screen from it – probably in a really flat two-tier architecture. Where’s the value? Last week I was invited to to be on a panel on model driven development, including leading academic and commercial experts. Each of the members of the panel had to introduce their position and approach briefly to the audience. This noteworthy event learned me two things. One: never to allow four enthusiastic innovators talk freely on their innovations. The word briefly isn’t in their vocabulary. And two: coming from a more or less commercial background, you don’t have a clue to what model driven development does in the academic world. A whole new spectrum of approaches met my eye. So where’s the value in all this? Well, following a good old Scrum adagium, I would have to say: that depends. To put it bluntly: generating code from a model can be very rewarding for projects, but I’ve also seen projects that make quite a mess out of it. Being successful at model driven development, in my honest opinion, requires some prerequisites to be met:
- Embed approach. Successful model driven development projects I’ve seen all share a single principle: it’s all in a days work. Model driven development should never be made a goal as such. It’s a means to make better software faster. Thus, modeling and code generation should be embedded as normal work in the project. Nog guru’s, no heroes.
- Allow changes. Projects go through changes. That’s a fact of life. Model driven development should not be the blocking technology, but rather should stimulate creativity, by allowing project to quickly show what effect new or changing requirements have on the software being produced.
- Stabilize architecture. Knowing where to generate what code is key for your projects. What aspects do I need to model and what code comes out of it. I stronlgy recommend to set up a stable software architecture model, with accompanying frameworks, and try this out, before elaborating on code generation.
- Be pragmatic. My general advice in life also holds for model driven development. Be pragmatic. Don’t overdo it. Don’t try the squeeze the whole world in the model. It’s not necessarily a bad thing to still have to write some code if it is easier to write than to model.