The UML Learning Path

(Click picture for a larger image.)

The UML Learning Path

No, I’m not going to name any of the devs who inspired this post. They wouldn’t know who I am, anyway.

But it takes an extremely high degree of arrogance to go from “I don’t see a way to use this” to “This has no value, no matter who says they’re getting value out of it. So I’ll dismiss it, and I’ll mock them” Either arrogance, or more likely, insecurity: “I don’t understand this; so since those people think it’s important, either they understand something I don’t, or they’re fools. I’ll mock them, so everyone thinks they’re fools. That will make me look smart.”

And that insecurity manifests in a lot of places on a lot of topics, not just UML: Agile Development, Orchestrated Development, CMMI, Test Driven Development, C#, Java, Ruby, linux, .NET… Any time you move from “I don’t see it” to “It’s worthless”, look around: if other developers are putting those tools to productive use, then it’s not worthless. It just doesn’t help you. So do you call it worthless, and imply they’re fools? Or do you openly mock them, demonstrating that you’re a fool?

Or do you follow the only exit path in this diagram? There is only one, after all. Once you get UML, you’ve gotten it for good. You may not use it all the time, but you’ll understand when and why you should use it. But the only exit path is the middle: you recognize that UML (or Agile, or Orchestrated, or…) is having some value on some projects, so it’s not worthless; but you just can’t see the value. You remain open-minded.

Leave a Reply