Writing better software faster

Published in my Interesting Things column in SDN Magazine, November 2009.

Looking back on twenty years of software development, I must have spent most of that time trying to improve the quality and productivity of software development.

Ever since I started to write small applications in Turbo Pascal in 1988 I got infected with the writing-better-software-faster virus. Right after I finished the second of fourteen of these applications, I wrote my first framework. It took some effort, but writing the following twelve applications took me less time than building the first two.

Darkening perspectives

There are good reasons for increasing productivity and quality. First of all, we have to increase productivity by a hundred-fold to meet up with current demands, says Gartner. Furthermore, technology is becoming increasingly complex. Ten years ago I was working in both Microsoft and Java projects. Anno 2009, I’ve let go of the idea that I even have an overview of either one of them. It is hard enough working with a small subset of frameworks. A Silverlight designer is not likely knowledgeable in NHibernate. Being a Spring guru does not guarantee foxy JavaFX user interfaces.

Despite this darkening perspective, there’s techniques and technologies that might keep you from drowning, by simply raising the level of abstraction. Good frameworks help. Smart use cases certainly do. And even UML assists. And then there’s model driven development a.k.a. model driven architecture a.k.a. model driven engineering a.k.a. domain specific languages. Different names for generating code and other deliverables from a model. What model? To be honest, any model will do the trick. Business process models, use case diagrams, user interface models, domain models, and last but not least data models.

Empirical start

Eight years ago I was helping a customer set up the domain model for a help desk application. After that I started to build the software in ASP.NET. Having modeled all domain objects, their properties and their services, I was typing them out in C#. So, as any decent developer would do I wrote a code generator. That helped.

I suspect most code generation efforts have a similar empirical start. That’s probably why there are so many approaches to generating code. Some really high-brow, squeezing everything-and-the-kitchen-sink into a model, and then trying to generate the whole application. From front  to back. Or, at the very low and of the spectrum, inspecting the database, generating create-read-update-delete screens in a flat two-tier architecture.

Where’s the value?

Recently I was invited in a panel on model driven development, together with some academic and commercial experts. For starters, each of the panel members introduced their position briefly to the audience. This noteworthy event learned me two things. One: never allow four enthusiastic innovators talk freely on their innovations. The word brief isn’t in their vocabulary. Two: coming from a business background, I didn’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 this? Following the good old Scrum adagio I’d say: it depends. Model driven development can be highly rewarding for projects. But I’ve also witnessed projects that made a terrible mess of it.

In my opinion, being successful at model driven development requires some preconditions to be met:

  • Embed approach. Successful model driven development projects share a single principle: it’s all in a day’s work. Model driven development is never a goal. It’s just a means to an end. Making better software faster. No guru’s, no heroes.

  • Allow changes. Projects go through changes. That’s a fact of life. Model driven development should never be blocking changes, but rather should stimulate creativity, by allowing projects to show quickly what effect new or changing requirements have.

  • Stabilize architecture. Knowing how to model, and where to generate what code is key. Set up a stable (layered) software architecture, pick frameworks that match it, and only then elaborate on code generation.

  • Be pragmatic. My general advice in life also holds for model driven development. Be pragmatic. Never overdo it. Don’t try to squeeze the whole world in your model. It’s not necessarily a bad thing to still have to write some code manually.


Having said all that, and having seen projects that very successfully apply model driven development, why is there still so much skepticism? After all, the paradigm really helps to deliver high quality at high productivity.

After witnessing both highly successful and extremely failing model driven development projects recently, I have given this some consideration. The vast majority of projects are in the middle of the wide spectrum of approaches. They run smoothly, being fairly practical. But it’s the failing projects at either end of the spectrum that draw the attention. Highly complex, slow moving, rigor projects on the one end, and oversimplified, bug-absorbing, underestimated projects on the other end. It’s no fun at either end.

No Jedi knight

My team and I have always adopted a highly pragmatic approach to model driven development, modeling smart use cases, applying domain driven design, run the model through our code generators (Tobago MDA) and we’re set to go. We do make better software faster.

Can life be this simple? It certainly can. We have applied this approach to all kinds of projects, and generated code in a variety of languages and frameworks, from Visual Basic to C#, from PHP and Java to Cobol. At the upcoming SDC, I’m going the check out a combination of Silverlight, .NET RIA Services, ADF and probably Fluent NHibernate. Should be fun!

To leave you with some words of wisdom (ahum). If there’s one thing I’ve learned from being successful at model driven development, it’s this: modeling and generating code should be everyday practice in your project. There’s no such thing as a “model driven development project”. There’s only software development projects. You don’t have to be a Jedi knight to steer a code generator. It’s all in a day’s work.