The role of models in Agile and Model Driven Development approaches

2009-04-5

When I was at the university, I remember being very interested in the suggestion that building software was like building bridges, and that software should have blueprints as sophisticated as those needed to build a bridge. I remember to has been told that you will never find a book on “How to build bridges in 7 days” but you will find the equivalent on “how to learn C++ in 7 days”.

Today, I’m not so convinced that this analogy is a good one. I can’t agree more with this quote from Dave Thomas (the Pragmatic Programmers proposed a new analogy that I’m pretty sure not everyone can digest):

Software development is neither. Nor is it art. It’s just software development. People who look for the “software is like xxx” analogies are missing the point. Software development is like software development. Let’s decide what works for us, and have fun while doing it

If you are interested, Martin Fowler explains the reasons why the building bridges analogy fails. I think, there is a sentence in his article that summarizes the problem very well:

Can you get a design that is capable of turning the coding into a predictable construction activity? And if so, is cost of doing this sufficiently small to make this approach worthwhile?

This question is, obviously, rhetorical. You won’t. Traditionally, the gap between models and code has been huge. If you ignore this gap, then you may think that you have to make great efforts in creating very rich models, so the low-skilled and no-talented programmer can translate them into working code. And if you can create these models, then nothing stops you from planning the full development process up-front. Since the construction phase is mechanical and predictable, then you only have to calculate how much time you will have to spend in modeling. And since modeling is about drawing (if we use this development approach we are using UML for modeling everything for sure), this estimation should be easy too. After all, drawings, like Word documents or Power Point slides, always compile and work. Of course, this scenery would mean that software projects are delivered on time, that the waterfall approach works, and that no matter wether the developers are talented or not.

In my opinion, the fact that models can’t be converted into code easily is addressed by the two development approaches I am more interested in:

  • Agile development

  • Model Driven Engineering (MDE)

Although both approaches are perfectly compatible, they propose different ways when it comes to use models. Both approaches see models as a communication tool, as a resource that let us, as humans, reason and elaborate solutions that solve complex problems. While agile practitioners warns you against using models for anything more than this, MDE practitioners propose to take the next step and convert models into first-class development artifacts.

The two approaches give different answers to the question of being able to create designs that can turn the coding into a predictable activity:

  • Agile developers’ answer is “no”. In fact, they propose to use many good development practices and exhaustive testing as a shield against problems when coding. Coding is not an ugly phase, neither is cleanly separated from design. There are not designers and programmers, there are developers. They will use models as a way to collaboratively obtain the best designs that solve the problem, not as a way of documenting it. And since they assume they can’t predict how the full process is going to be in earlier stages with detail, they are going to estimate and develop the project iteratively, using an empirical estimating approach.

  • The MDE answer is a little bit more complex to say, since the paradigm is in its earlier stages. But if we manage to have MDE solutions where we can define the best DSLs to describe a problem, and to specify how this input is translated into a working application, then, if these DSLs are defined in a way that are reusable in different instances of the same problem, we would be very close to being able to answer “yes” to that question.

By the way, a confluence of both approaches can be seen in the BDD (Behavioral Driven Development) frameworks: such as RSpec, Concordion or Cucumber, but I think that topic deserves a post on its own.

There is 1 comment in this article:

  1. 2009-04-6Mike Jones say:

    Models cannot be converted into code easily? I have to disagree with this statement. If you have been a developer for more than, say 12 years, you will undoubtedly remember the days of CASE tools. Several of these products did an excellent job of generating code from models. The problem was that the models were developed using a waterfall approach (Information Engineering was the most common method) which ended not accurately representing the business need. And since we spent all the time up front modeling to get it ‘right’ we did not show the end users a working solution until everything was done. The end result, applications that did not meet end user expectations, were late and cost more than estimated.

    In my experience Agile directly addresses the issue of an inability to accurately specify exactly what the business needs as a requirement. Why? Until the end users see the working application they cannot accurately imagine how it will support their process and how they might modify their working process to accommodate automation. Thus Agile’s iterative approach allows us to deliver early and often taking into account feedback from the end user community as we go resulting in fit for purpose applications that only deliver the needed functionality to meet business needs! Of course if we manage the project, its backlog and work with the business to trade high value needs for lower value items we end up delivering on time and in budget!

    To learn more about the approach we use go read our methodology white paper titled ‘Eight stages of an Agile approach that works’. You can find it at this link under white papers: http://tinyurl.com/dmnf8w.

Write a comment: