UML Hell Doesn't Exist.

Recently, customer gave me a paper that basically said that modeling is a mistake and that it takes too much time for the benefits.  The author states that UML is strictly an academic concept that has no place in the commercial world.  He states several problems including the model not representing the code and modeling slowing down the development process.

Obviously, I disagree.  In fact, I disagree so strongly, that I'm not going to give the link to the paper.  I will, however, share what I told my customer.

True, modeling just for the sake of modeling provides little value.  It is entirely possible to model to such fine detail that the model misses its purpose.  In the Systems Engineering realm, the purpose of the model is to specify what the system must do, not how the system does it.  Any modeling that describes how is a waste.  The advantages of Systems modeling are fewer missed exception conditions, fewer duplications of effort by multiple subsystems, better definition of the interfaces, and better understanding of the subsystems' responsibilities.

In the software realm, models show the desing -- how the system implements the requirements.  I am assuming, of course, that you see value in designing your system before you start coding.  Typically, designs include the software structure, class/file interactions, and function/method behavior necessary to build the software.  A UML model, therefore, includes the exact same information you are required to deliver in an SDD.  In fact, you should generate your SDD directly from your model.  The advantages of software modeling include better understanding of  (by all stakeholders) of the system's functionality, better design reviews, better structural design, less time to develop code, and increased reusability.
If you use the right tools, modeling decreases development time.  There are several tools on the market today that generate code directly from the model.  Now, the "fitness" of the code varies with the tool.  Some require you to make all changes directly in the tool;  the code is really not user editable.  Others, produce only "code-frames," the header files and the method signatures.  I don't recommend using products like these.

Instead, find a product that generates full, production quality code directly from the model.  The code should be readable and editable with your favorite editor.  Similarly, you should be able to use your tool to visualize existing code.  (email me and I'll give you the names of the tool I like)

The proof of the pudding is in the tasting, so rather than get in a war of words with the author of the other paper, I'll point to Dr. Jerry Krasner's paper What to do When the Horse You're Riding Drops Dead.  Dr. Krasner's research showed that organizations that model and generate the code from the model finish their projects on time and hand code fewer lines of code to accomplish the same task.

I also add my own experiences.  I used to run a software development group that produced the machine control software for high speed mail sorting equipment.  My development team had 5-7 people.  We developed routinely developed more code, in less time, with fewer erros than groups of 15-20.  The other teams had to stop developmetn for 2 weeks a quarter to update documents.  I generated our documents while the team was at lunch.

Bottom line:  UML helps real projects develop software faster and with fewer errors.