ZDNet UK

• CNET NETWORKS UK BUSINESS SITES:
• atlarge.com
• BNET UK
• silicon.com
• SmartPlanet.com
• ZDNet.co.uk

Making sense of agile modelling

• Tags:
• Documentation,
• Evolve,
• Courses,
• Skill

Nick Gibson Builder AU

Published: 10 Jul 2007 15:19 BST

• 
• 
• 
• 
• 

It's common for many programmers to be suspicious of modelling, but it doesn't have to be that way. We talk to IBM's Scott Ambler about how you can use agile modelling for any project, and why you probably already are without realising it.

Q: What does agile modelling mean to developers in the Web 2.0 world?
A: The goal of agile modelling is to describe a collection of principles and practices for modelling and documentation, preferably on agile projects, but, if they're not so agile, then that's OK too. What we've seen is that the major use was in XP [extreme programming] to make modern documentation more explicit, or with the RUP [Rational Unified Process] to sort of ramp down some of the bureaucracies and make it as streamlined as possible.

It just describes ways for you to be effective with thinking through some of the things you're doing without taking a hit from needless documentation. From an agile point of view, it gives some explicit strategies for how to protect yourself from the bureaucrats who want you to do way too much documentation, and provides some advice to govern some of the things you're doing.

Some of the more extreme rhetoric in the agile community really motivates some people to do the wrong thing; not picking on agile fans, but that's probably the wrong way.

What do you think the general opinion from programmers is on modelling in business?
I think that a lot of programmers struggle with modelling, for a lot of reasons.

First, they haven't got good training in it. I don't think that schools do modelling justice at all. They might never for all I know, but they certainly don't do it well now.

A lot of the time developers will show up to their first job and, the first time they do modelling, they'll almost always be put into one of two dysfunctional situations. Either they'll be put into a project team where you're given all this modelling up front, and then you ignore it towards the back-end. So they see all this wasted effort around modelling documentation and then they say: "Hey, I did all this modelling and it didn't have any effect on the product whatsoever, what a waste!" And so they get bitter about modelling.

Or worse yet, they'll do the work, they'll successfully deploy the project into production and then someone will come along and say: "Well, now we need to spend the next two months writing all the documentation we should have to make it look like we followed the process." That is a complete waste of effort. That's just somebody justifying their job; it has nothing to do with delivering value. A lot of developers get bitter about this sort of stuff.

Another common issue is that they struggle to distinguish between modelling and documentation. If I'm doing a sketch on a whiteboard, then that's a model, but it's not a very good document. What will happen — and in a way the fault lies with the vendors because we want to sell Case tools — is that we try to convince developers that modelling has to be done with these heavy tools.

Well, no, not all of it — and let's just observe the fact that a lot of modelling will happen on whiteboard and it will happen on paper, and that's perfectly fine. When you want to get more sophisticated though, you need more sophisticated tools. For example, I've got pretty good modelling skills, so I'm far more effective using a tool like RSA [Rational Software Architect] or RSM [Rational Software Modeler] to do my modelling, and then generate my code and generate my database stuff than I am "hand-jamming" it.

It's just crazy writing code when I can generate it — I'm assuming that the tools generate decent code here. The problem is, though, that it requires a heck of a lot of skill — if you don't have that skill, and haven't taken the time to get it or…

• 
• 
• 
• 

• Share this article:
• 
• 
• 
• 
• 

• Most Recent
• Most Popular