UML and UML tools seem to always be getting a lot of bad press. This might be the result of developers not utilizing them for their intended purposes. As they were originally imagined, UML diagrams should only be used when designing code. They should not be used when sitting down to detangle a pile of incomprehensible logic or making sense of an alien design pattern; and especially not for generating all your project’s code. Experienced designers may already have come to this realization but for others some explanation is in order.

There are a lot of options when it comes to UML diagrams. Other than the ever present Class Diagram there are: Structure Diagrams (class, deployment, package, etc), Behavior Diagrams (activity, usecase, etc), and Interaction Diagrams (communication, sequence, etc). They are all used to meet a very specific need; communicating design requirements from product management to the development team. This is very important when working with most software processes since they require all functionality to be determined during the design phase. Five months later when features are added/removed and code is re-factored, maintaining the UML diagrams becomes tedious and the diagrams are no longer helpful.

Recently Microsoft NERD hosted a talk by David Platt, and according to David, users think that today’s software sucks. He says it is overcomplicated, too hard to use, and simply doesn’t get its job done. It is true that software is a top consumer complaint. David cites statistics from the Better Business Bureau regarding most complaints received per industry, and software industries appeared three times in the top 7 in 2006 and three times in the top 5 in 2007.

But before you slit your throat, I say consider when viewing these statistics how ubiquitous technology and software services are today. Even if a much smaller industry sucked a lot more, software industries would still rank higher in a list of the number of received complaints simply because the number of consumers in the small industry is far less than the number of software users. Really what I’d like to know is the number of complaints our industry receives compared to the number of possible complainers (our users). Of course, regardless of whether these statistics are the best gauge of user satisfaction, it would be foolish to not make an effort to determine what the complaints against your software are or to ignore major design flaws.