On UML
I’ve been reading Arnon Rotem-Gal-Oz at Doctor Dobbs Journal for a few months now, and it makes very interesting reading. He writes on various aspects of architecture technique and principles, and even if I don’t always agree with him he is always well thought out.
He made a point in his latest post about UML, which I agree with most strongly though. He is a believer in UML As a Sketch, as am I. This position seems quite unusual amongst a lot of the people I deal with though, and for cultural reasons.
One of the things I find very interesting about the difference between proprietary software and open source is the very different approach to architecture. Because of the top-down nature of proprietary software projects, there is often someone appointed as Architect who can then, more or less, direct development. In this environment UML thrives, with huge pieces of analysis and design being done using UML, which is then given to developers to build (often with stubs for all the code generated automatically be modelling tools).
In Open Source software, there is no way any one person can be ‘architect’ in the same sense. Your developers can generally do their own thing. The only way to make them do something one way is to demonstrate that it’s best - and the only way to do that is to write some code, and show it working. It’s easy to argue about models, but hard to argue with running code.
Some of the most impressively architected Open Source projects I’ve seen are designed on IRC and mailing lists by groups of very highly skilled developers. They don’t use UML, in part because their medium is text only. In fact, UML seems to be generally regarded as a crutch for the feeble - real developers talk in code. During the tool-heavy eighties it was generally thought that large complex systems could only be developed using ever more large and complex support systems, but these guys most definitely refute that.
I am, unfortunately, one of the feeble, and I find UML can really help me think. Often I pop open MagicDraw, start knocking out a few diagrams and within 10 minutes the solution has crystallised in my head, and I can drop the diagrams and start coding. But the visual nature of the design, and the constraints it imposes on how you approach the problem are really useful. So, on this point at least, I agree with Mr Rotem-Gal-Oz, even if often the only person I am communicating with is myself!