Making sense of agile modelling
Published: 10 Jul 2007 15:19 BST
…been in a situation where you can work with someone who does it, then that's pretty rough. A lot of developers are finding that, given a choice, they'd do more modelling, but they haven't had the opportunity to learn it well.
We definitely need to distinguish between models and documents. They're totally different concepts and, while some models will evolve into documentation, many will not and that's perfectly fine.
How strong is the connection between modelling and documentation?
It's very strong in the traditional world, which is why we're all so hung up on it, but really it's not that strong at all. Ninety percent of modelling is done on the whiteboard and, in a recent survey we did, modelling turned out to be the fourth most effective practice being done on teams. Paper modelling was not that popular, for all the stories about user stories and CRC cards and whatever, which is what I like to see.
The vast majority of it is done in these throwaway kind of models. But you can make a very strong argument that writing a test before you start writing your code is actually modelling; you're specifying your program before you start writing it. Just because I'm not doing a UML diagram doesn't mean I'm not modelling.
Just because I'm not doing a UML diagram doesn't mean I'm not modelling
Scott Ambler, IBM Rational Software
Most models will not evolve into documentation — some will — but a common thing you'll see in an agile team is whiteboards everywhere and people drawing models and so on, and over time you'll see them evolve. What will happen when you get down to writing documentation is that the models that survived on the boards are the useful ones, the ones you put into your tools and you write-up and make look good and so on.
On the educational side, what do you think needs to be done to fix this situation?
Well I think universities struggle with a couple of things. Firstly, they just don't have near the funding they need, and they never will — that's just the way it is. They also, for whatever reason, tend to shy away from group work. Modelling is a group activity and you need multiple people to do it, and you need to work together. If you are doing assignments and you are asking individuals to sketch stuff, then that's great, but they'd probably just as well be banging out code. They also chop things up into different courses, so you get the Java course, the database course, the mathematical theory course, so what happens is that the focus is just on numerical programming or whatever and they never bring the full lifecycle in.
The other thing is that they don't do projects; they'll do problem sets or they'll give you an assignment to go off and build something, but they don't say: "Let's work on this system for the next two years of your degree," and so for two years they're working on different aspects. You're not getting any real-world experience.
I'm not saying that it's easy to do, but these are the things that they need to start doing. I was working at the University of Toronto years ago and one of the things we did, and it was really hard to do, was, in this group-work course, we told students that they'd be developing a system all the way, then, in the middle of the way through, we yanked all their stuff and replaced it with work that had been done in previous years and said: "Okay, now you're maintaining a legacy system; what are you going to do now?"
They were shocked; there was all this whining and complaining about how evil we were, but that's the real world. In the real world you have to maintain someone else's code. I've run into people years later and they've said that it was the only course that was actually useful to them, and it's because that's what happens — that's real. You need to simulate things like that, and it's hard.
I want to know: why can't a third-year computer-science course just take on an open-source project? Why couldn't the assignment be that these three people work on some project they want and…
Full Talkback thread
3 comments





