Russell Beattie writes:

Anyways, I've since seen the value of UML, but not as a programming aid per se. I need to see that in practice with my own eyes, because I don't see it helping all that much. But what IS nice is when you're trying to communicate process flow on the whiteboard, or in a document and having a common graphical vocabularly to use.

Me too. I know about enough UML to draw pretty sketchy class, state and interaction diagrams. UML works very well as a common vocabulary for communicating design between developers, or for documenting critical parts of a design. There's nothing magical about UML, though, and sometimes it's possible to go overboard and spend more effort drawing the pictures than you get value out of them.

I'll happily admit that I probably get a thousand technical details in my diagrams wrong. That's cool because I'm only using them to communicate a pretty broad intent—I don't even expect the code to be 100% faithful to the diagram. That's another advantage of whiteboards, you can wipe the pictures into oblivion when they're no longer useful, and they don't leave confusing artifacts behind.

If you're doing enough detailed UML that you can take advantage of those tools that generate code from the diagrams, you're doing far too detailed up-front design in my book.