Many great points made, both the OC and in these comments. Another methodology pitfall (in general, not just UML) was working with other humans. It's just so h

Many great points made, both the OC and in these comments. Another methodology pitfall (in general, not just UML) was working with other humans. It's just so hard to get everyone onto the same page. Just one tiny facet of UML are use cases. I love the book Applying Use Cases: A Practical Guide. Short, precise, actionable, repeatable. It's basically just a recipe. Almost too easy. TLDR: All architecture must be tied back to use cases. No brainer, right? My company did a lot of continuing education. So we all read Applying Use Cases, have multiple bookclub style discussions, try to use the methodology during a project kickoff (bridge from requirements analysis to high level design). Holy shit. You'd think we all had read different books. There was no shared understanding for any of the concepts, how to proceed. All normal pedantry (defining "use case", arguing over system vs user, correct level of abstraction, questioning the requirements). Plus the new arguments about tracing "use cases" to "architecture". FWIW, that was the effort that broke me. After a few years of being a methodology warrior, I just gave up. At work, I want to ship code, not debate philosophy with bozos. I still use various OOA/D techniques and skills I've acquired. But only for my own benefit. Either I'm in a position to just tell people how it's gonna be. Or I keep my mouth shut. Fortunately, XP and Agile popped up. Enthralled all the poseurs and PHBs. Leaving me (and my teams) alone to just focus on shipping product.