Over the course of my education career (by which I mean receiving education, not partaking in education as a career), I've studied UML in four different courses. Or is it subjects. In Australia they're one thing, in the United States they're another thing, and Singapore tends to drift between the two. So much so, that I've already forgotten which to use. Of course, the adequate one is subject to opinion, as a matter of course.

Golf courses

I've studied UML in high school, at two universities, and once in industry as part of a course. There's that word again. With an exam on much of UML tomorrow, I've been burying my face in them once again, plowing through all these different examples, coming up with alternatives, refining and redefining and refining.

As someone who loves drawing diagrams, flow charts, mind maps and other such visual stuff, UML is a natural fit for me. Or at least, you would think so. To me, it has several problems.

And here are those problems

But but but…!

I can already picture the responses I'd get to these concerns by those who use UML for a living. Even standards that are only loosely enforced across industry and academia are better than no standards at all. Strict syntax ensures consistency. While each of the diagrams in the suite may have redundant information compared to the others, different stakeholders and developers would look at only a subset of them tailored to their needs, so that would be less of a concern for them. Work isn't supposed to be fun, and you can still be creative by colouring inside the lines. Abstraction makes implementation easier.

I understand these points, even if I can't entirely appreciate them at this stage. To be honest, I've been more at the development stage of the cycle than the requirements gathering stage. Still, I worry that buried in the hype and promises, there's a lot of hot air and solutions in search for problems in UML. A quick net search shows I'm not the only one who thinks this, not by a long shot!

UML is better than perhaps other modelling solutions we have at this stage, and I can churn them out and understand them fairly well… or at least as well as someone in my position could! However, there's still far more work to be done in bridging the gap between requirements and development. Whoever figures out how to do it better will be a very, very rich person.

I'd suggest taking a long, hard look at the KISS principle. That sounded terribly, terrible wrong for some reason.