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.
A lot of modelling will happen on whiteboard and it will happen on paper, and that's perfectly fine
Scott Ambler, IBM Rational Software
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…
Talkback
I think the author is talking out of both sides of his mouth here.
The fact is: Software developers today are really designers and not coders.
The reason that business anlaysts exist today to model solutions is because they understand the value of designing software before writing it.
All too often developers create code that has little value because they do not understand that business classes interact with other classes within the confines of a working model or pattern.
Effective software cannot be created without somebody designing a solution first.
I have delivered OO models and other design specifications for years to software developers who were shocked at how effective coding became after learning design and modeling skills.
When I were a lad we had to flowchart the project up front and comment everything we wrote while putting it into binary, Assembler, Algol, FORTRAN or whatever - so WE knew what was going on afterwards, never mind those who came after us. The code was simply the mechanics of execution of the flowchart logic on a computer, a computer should have been able to do it - now I gather one does?
The problem throughout my career in ICT product management has been software written by coders who don't do either before they start, its called job security , contract renewal or a support contract at EDS et al. Maybe you can be this sloppy with higher level languages? What say you, professionals?
Is old grey ACE/Deuce best practice any different with today's much higher level languages?
..... on a credibility note its hard to take anyone seriously who wears a white sunhat for his bio pic in a serious professional column.
Hello Coder!
Brian
This post has been removed by a moderator.
Well stated!