So far, this is a minor modelling point, and maybe not one which you care about too much. But what made these two events memorable was the differing reactions of the two teams.
One – the Use Cases team – was very reluctant to change their model. It had been produced by several people over many weeks, and had 100’s of use cases. Changing it would be hard (it wasn’t, as it happened – we wrote a little EA script to fix it).
The other team also had lots of processes, listened to the arguments, and immediately decided to change to a more ‘normal’ style.
Now I wish I had a neat theory as to why one team was reluctant to change, and the other not. The ‘process’ team had much more modelling experience than Use Case one, so maybe they felt they understood the argument better. The Process team had already been given lots of feedback on their model, so maybe they were happier to take external suggestions: the Use Case team were blazing a trail for model-based development, so hadn’t had much external feedback.
My learning points – which I’m going have to apply to my own models 🙁 are therefore:
- Don’t get too attached to your models. It’s just a way of writing stuff down, not a part of your soul. You’ll leave them behind anyway some day. It’s not personal.
- Get other people (who know something about modelling) to look at your stuff, as often as possible. They may know even less than you, but two pairs of eyes is always better than none. And the less they know, the more chance they will ask the ‘stupid question’ which turns out not to be.