Analysis Paralysis : Getting Carried Away With UML

UML is a useful tool, no doubt.  It’s a tool to help model complex logic in a visual manner.  It’s a language in and of itself and it can aid in communicating design ideas with exacting precision, leaving little room for error.  However, at the same time, as with any formal language, it creates strict rules for communicating in that language.  Syntax, vocabulary, “grammar”…these all apply to propperly using UML.

Myself, I’ve never been a big fan of UML.  There are different ways to convey ideas, intent, and understanding of a set of requirements, but imposing UML is like asking a blogger to write all of their posts in iambic pentameter when prose would work just as well.  What’s the point?  Your colleagues can already all read English, but not everyone reads UML…why add that burden and rigor?

There’s a big difference between the rigor required to build a bridge and the rigor required to build a web application.  Miss your target by a foot, and it’s a multi-million dollar mistake if you’re building a bridge.  If your bridge throws you an “unexpected exception“? You’re talking possible risk of life!  A web application or a portal?  Unless there are fundamental, framework level mistakes, most changes are negotiable; it’s software for a reason (and oddly enough, on large projects, the cost overhead isn’t necessarily associated with the development side, but with the business side and the specific processes for validation, testing, and change management – maybe those guys need to fix their processes…).

Now this isn’t to say that getting it right isn’t important, but at some point, process and progress starts to drag as you impose an inordinate amount of rigor.

With regards to sequence diagrams, Scott Ambler puts it very well:

The most important things that you can do is to keep your diagrams simple, both content wise and tool wise.  I will sketch sequence diagrams on whiteboards to think something through, either to verify the logic in a use case or to design a method or service.  I rarely keep sequence diagrams as I find their true value is in their creation.

A common mistake is to try to create a complete set of sequence diagrams for your system. I’ve seen project teams waste months creating several sequence diagrams for each of their use cases, one for the basic course of action and one for each alternate course.  My advice is to only create a sequence diagram when you have complex logic that you want to think through – if the logic is straightforward the sequence diagram won’t add any value, you had might as well go straight to code.

I agree wholeheartedly; the exercise itself is more important than the final artifact.  It’s far too easy to interpret the intent of UML incorrectly; the value is not the artifact, the value is the process.

At the end of the day, it is not a silver bullet! It doesn’t make your design more complete.  It doesn’t mitigate all of the risk.  It doesn’t make your intent free from misrepresentation or misinterpretation.  It doesn’t make a design document bulletproof.