Camelot, Camelot, Camelot ! It’s only a model…..

A frequent confusion about Agile/Iterative development in general and XP in particular is surrounding the cultural clash of up front modelling and incremental development of the data/domain model. Cries of “How can it possibly work?” and “I’m sure that they’ll never be able to handle anything complicated without modelling”. I don’t wish to deny people the right to believe what they want, because they’ve probably got years of “doing it this way” and the cultural shift is hard for people to take.
Sadly, most of the time I hear these cries, I look at the code, or run some metrics tools over the code and it’s a load of crap. Quite often the model is clean, well considered, but the implementation is unmitigated rubbish. I’m sure there are people that can predict exactly how the application shall be modelled, and have enough experience in development to know how that will translate to code and do a great job. Those people appear to be very thin on the ground.
However what I have noticed is that developers who use TDD as a development technique as a way of incrementally growing the domain model develop substantially better code than systems that have been developed using a modelling tool up front (think Rational Rose, XDE) and then coded. This is a result of both qualitative and quantitative observations.
Why ? Well, I don’t really know, but I’d guess that it has to do with the following quote I heard from Jason Yip.
No plan for combat survives first contact with the enemy
A modelling tool is planning for implementation. It’s planning the code, it’s working out how stuff should be implemented. It’s not actually doing the work. It’s not until you actually write the code and have the environment impact on your code, and your fellow workmates impact on the code and the customer changes the focus that you really know what you’re going to build. What’s more, there appears to be a “we modelled it up front, so there is no need to re-evaluate the decisions” to this sort of development. Incremental development techniques are constantly working on the code and revisiting decisions. There is constant review and validation of decisions, rather than a single, up front guess.
So, while I think it’s possible to specify a system using a modelling tool and have that model implemented in code and have this occur successfully, I don’t think it’s something that should be seen as a desirable mechanism for building software. This is mostly due to the human factors involved. If people think that the “design is done” as a result of the modelling, then what remains is just to type the code, and sadly it appears that people will park their brains at the door and development will proceed poorly. If the development team can manage to continually revisit the design decisions and validate the progress by way of metrics and reviews then I believe that the results can be sucessful.
To the claims of “Modelling is the only way to develop complicated software”, well, I think the French Knight said it best, “I fart in your general direction, now go away before I taunt you a second time.”


10 thoughts on “Camelot, Camelot, Camelot ! It’s only a model…..

  1. Models create complexity

    Up-front planning, a method I loudly evangelized until recently, inevitably leads to “unmitigated rubbish,” as Jon Eaves says. I’ve seen this in action, but even if I hadn’t I’d still believe it. Even so, I sometimes have to remind myself…

  2. what size domains are you talking about here? how do you enforce consistency in very large teams?

  3. The domains are significant in size, but I don’t have anything to compare against. 6-20 people for 6-24 months size projects.
    Consistency is “enforced” by the team, and by having senior people working on the project writing code.
    I’m not exactly sure what you mean by consistency, but the only time I’ve seen inconsistent code quality and style is when there is “up front modelling” and then the team is left to “do their own stuff”.

  4. Domain modelling, agile methods, and the limits of systems.

    I want to stitch together two seemingly completely disparate ideas here regarding domain modelling. Recently I have been architecting the client’s domain model in the system we are building. I haven’t been building the model itself, we have been thi…

  5. john, i was thinking of domains where the business has a very close and intimate relation to the domain (ie. it’s not a /model/ per se), and to the situation where there are large parts of the domain that are external to the application (e.g existing systems).
    I’m not one to say that up front modelling is a good thing a priori, but that sometimes there are external concerns that mean, within any iteration, there should be close co-operation with a data modelling team who carry the primary responsibility for ensuring the quality of the model.
    Anyway I wrote an entry and trackbacked to you in more confusing detail. 😉
    Also, a little doubt just occurred to me. You say, ‘”up front modelling” and then the team is left to “do their own stuff”‘, but how do you know it’s the former and not the latter causing the problems?

  6. I’m talking about domain objects and relatively fine grained modelling of objects/classes. I’m not talking about understanding how systems talk to each other. I think it’s very important to understand what your landscape looks like.
    As to the second point. I believe it’s a cause and effect thing. If you “do stuff up front”, you have a tendency (human nature) to not look at it again, and just go about your own way. Surely this is a common enough situation, documentation goes out of date is one of the commonly noticed symptoms.
    I maintain very strongly that it _is_ the latter that causes the problem, but I’ll also say that the latter is caused by the former. (Because people are slack)

  7. I’m talking about the fine grained point too … how classes are derived and how they relate to database ‘entities’ and so on. Even right down to the field level. Sometimes the ultimate representation is still derived from external data. Do you think that specialist data modelling or data architecture teams have no place in agile development? My challenge appears to get them to accept that the ‘model’ is far more than just the database and to accept some responsibility to input into the development of the classes themselves.

  8. I think that specialist data modelling and data architecture teams have a hard time adding long term value to an agile development team.
    I’ll be careful here (as I’ve already had a similar conversation in person with Jason Yip) and say that there’s a difference between ‘specialist’ and ‘expert’ where ‘specialist’ means ‘narrow focussed skill base’ and ‘expert’ has it’s usual meaning, and can have additional skills.
    I’d also point out that the domain is only one part of the solution (which we’re focussing on here, and I only mentioned domain once in my original entry) and that wasn’t the intent of my post. People model all parts of the application, including interactions so the entire set of the solution space is much larger.
    The problem I’m describing covers the entire solution, and not just the domain. Maybe the domain suffers less from the problem due to it being so tightly coupled with some external forces. I don’t know, I’ve not thought of it in those terms explicitly. Maybe simpler (less rich) domains have less problems and are capable of well defined upfront modelling and due to the nature of the objects can be implemented with less variation or risk of divergence of metaphor.

  9. This all reminds me of a conversation I had with a colleague recently in which we were discussing the ways in which our team throws around ideas very vigourously, with the senior members of the team often being skirted around to avoid bloood spatter on the clothes of passers by. I made the point that if you throw ideas into the ring half-formed, you are less emotionally wounded when they get shot down or perverted, since your investment risk is low. It seems to me that what agile development has over that other way of doing things is that it lowers the emotional investment and makes it easier to discuss the merists of things without limiting one’s superiors’ careers. If a ‘designer’ has spent six months ‘designing’ and I turn up to write the code, he’s really going to not want to hear what I think of it if it’s merit is low.

Comments are closed.