Making sense of agile modelling
Published: 10 Jul 2007 15:19 BST
…you'll still be documenting because nobody can deliver a system without documentation. That's just crazy, right; you need user docs, support docs, system docs — it's just the way it is. I would invite you to be really smart about that, and that's what agile modelling is all about, being smart about it.
If a developer is dismissive about agile modelling I would have to question whether they're doing a good job, and I can't imagine not modelling and still doing a good job.
A lot of developers are not worried by the idea of whiteboarding, but rather restricting it to a set of rules.
Yeah, but the thing is: what team is not doing some kind of modelling? I mean, just because it's on a whiteboard or it's in RSA or it's in Visio or whatever tool you're using that's not a commitment to overbuilding.
It doesn't mean it's got to go off to fantasy land and build all these useless frameworks for months and months and not deliver business value. What's wrong with these people who have no control over themselves to not overbuild? So you can choose to gain the benefits of modelling without taking the hit of overbuilding or over documenting. And it's a reasonable choice to make — most teams do it, they just don't know how to describe it.
If a developer is dismissive about agile modelling, I would have to question whether they're doing a good job
Scott Ambler, IBM Rational Software
Do you subscribe to the idea that code-generated products are generally of a lower quality than hand-written projects?
It all depends on the tools. So, for example, I would challenge anyone who does any kind of database development to write everything by hand. Use any of the leading data-modelling tools and they generate great DDL; they generate great triggers. If you're hand-jamming DDL, what planet are you on? If you have to handwrite a trigger, what the heck is going on? What a waste of time — that's just crazy. It was interesting, when I was writing my database book I had to relearn DDL, because it's been years since I've written it. I just load up a Case tool, model what I want, press the button and "Boom": out pops the code. Why would I write that?
On the Java side of things, why would I write class stubs, or constructors, or all this code for doing OR mapping and stuff like that? I can't imagine writing that level of code anymore. Sure, there's some tools that generate not-so-good code; you've just got to find the right tools.
Beyond mechanical triggers and the like, there's always been a move to abstract out the programmer from the whole process.
I've heard this vision for over 20 years now. It was crap then and it's crap now.
At the end of the day, you can't do that. You need such a high level of skill to make that work; you need such good tools and, at the end of the day, if I've got those skills, I can still code it faster.
What you really want to do is visually model the things that make sense to visually model, code the stuff that makes sense to code and have tools that allow both and do the right thing at the right time.
That's still not easy, but it's realistic. You're never really going to have a 100 percent modelling site. There's only a handful of teams that could do that — it's such a niche thing. You always discover that it's very small, very narrow and they're the only team in a company of 10,000 doing this.
It's so rare to see it in practice; sure it's possible, but why bother?
So you've mentioned the need for modelling skills and code-generation skills. Where do you pick up those skills beyond just finding yourself in that sort of environment, learning from someone who happens to have them?
It's pretty tough. I mean, you can take courses. You can learn to program in a course, I guess, but you don't [learn to program] right; you learn as you do it. You've got to do the work, so, when you're learning this stuff, you can get some training and that'll give you some ideas, but you need some mentoring, you need hands-on experience doing it — it's going to take time to learn.
If you think though that everyone is going to have a 30- or 40-year career…
Previous
Did you find this article useful?
20 out of 28 people found this useful
Digg
Slashdot
Del.ici.ous
Stumble
Reddit
Full Talkback thread
3 comments
