A nice list. Personally, I've always thought that "too complex" was the most essential reason. To really get the intended value out of UML (as opposed to, say,

A nice list. Personally, I've always thought that "too complex" was the most essential reason. To really get the intended value out of UML (as opposed to, say, cell phone pictures of ad-hoc whiteboard flowcharts), you need to put a lot of time into learning all its intricacies. Doing it right is a specialized skill, enough so that you probably need to commit a single person to maintaining the UML diagrams if you want things to remain coherent. But that's a problem right there. Smaller teams can't afford to commit a person to fiddling with flowcharts like that, and, even on larger teams, the need to communicate with that person in order to make sure the charts stay up to date is a large effort. When I was at a Global 500 company, we had regular meetings with the UML folks where we'd go over the charts, they'd explain what everything meant - none of the developers had sufficient UML expertise to independently understand the diagrams beyond a rudimentary level - we'd explain where things had drifted away from the spec, and back and forth we'd go until it all settled out. And I don't know what purpose all of that effort served, aside from satisfying a rule that had been passed down from above. Developers never went back and referred to these diagrams. Like I said, we couldn't really understand them, so it was quicker, easier, and more accurate to just read the code or talk to each other. Managers were even less able to understand them, and knew that they were only accurate up to the last UML sync-up, which means they wouldn't cover work in progress, which is almost always the thing they're currently looking to understand. So they'd talk to developers. And maybe we'd have a meeting to bring each other to speed on how it all works and how that's working out, and how it needs to change. And maybe, during that meeting, we'd draw an ad-hoc diagram on the whiteboard while we talk. And maybe, if everyone thought it was sufficiently useful, we'd leave it up there and write "don't erase" next to it. And the fact that there was no formal specification of the visual language turned out not to matter, in the end, because the diagram never needed to be a formal specification in the first place; it was just a mnemonic device to help everyone remember what was discussed in the design meeting.