In your next life, when you get the time, you should be writing a book.

I’m a paper man(and chalk(marker) board man as well) myself, so it’s great to see this under appreciated medium for software design mentioned here.

However, over the past 20 years, there have been times for me where simply writing down thoughts on paper seemed too vague and I couldn’t quite “see” what I was attempting to describe. So, I needed to give it some legs and get out my erector set, my legos, my ball of clay so to speak which for me is just a straight forward, plane jane, bit of programming that gives me a chance to mull over, further shape and thrash around my ideas. I use it as an erasable, disposable canvas so to speak. Artists and musicians do this all the time, they make throw away peices just to help them “feel” their way through a project. I’ve had some neat “ahah” moments doing this where I just couldn’t quite pentrate to that level of thinking on paper. I had to see a few moving parts, a few sprockets and gears, giving it life and breath.

Just my two cents and thanks again for this very well thought out take on software design.

My mistake: I forgot to explain that I was talking about online project where physical meetings are not possible.
In the oge (not ogre) project, I would love to have such meetings. Without them I use lots of chats but uml diagram are easier when a thousand words are not clear enough.

For more detailed design and formal reviews, fine, I agree. My point was that leaping into the UML tool before you’ve got a skeleton conceptual design slows you down, because the most important thing is to quickly evaluate and discard / refine as many ideas as possible, and that applies just as much for colloborative design, since it’s much, much faster to bash through things with colleagues on a whiteboard or scribbling on some shared paper than it is to write up ideas in a UML tool and exchange them.

If you’re distributed remotely the tool can be useful but then you probably still do each conceptual stage locally anyway, since it’s more likely to be a store-and-forward approach than a truly interactive design session.

I would just make a comment about the first one: it is too focused on one programer. If you need to make a collaborative project from the start, you can think the design on paper. But IMO you need to quickly make some uml to exchange and reach an agreement with the others programers. For that uml is good.

That said you are right that you must not lose your self in overdesign/overdocumentation. Only concentrate on a few (max 10) uml diagram: classes, deployment and a few sequences diagram is enough to make a team work in the same direction.

…