I used to develop a CASE platform for mission/safety-critical technical developers -- aerospace, datacomm, complex embedded (not corporate "MIS", which has morphed into "enterprise"). My company did some work that was ahead of its time, some of which would still be considered new and cool today on HN (and also boring stuff).
Based the recent carpet-bombing of UML comments on HN, I have a new theory about UML, and it's no longer that dotcommers have the strength of opinion that can only come from narrow experience (nor that the barrage is an accident of what I call blog-arbitrage)... :)
When Java first came out, it was one of the coolest things to be using. Then Java became an "enterprise" thing, and became very different. I'm wondering whether enterprise-sales-capture is what happened to UML.
Maybe the dynamic is IBM trying to sell enterprise products and training, orgs doing enterprise development wanting to have documentation and process standards, orgs mandating UML, lots of developers going through UML training, developers seeing UML as a checkbox expectation/requirement (like TPS cover sheets, rather than as a tool they find useful), etc.?
And that dynamic has driven the evolution of UML, as well as the examples-in-practice to which most developers have been exposed?
FWIW, even if UML has gone in a direction that's not applicable to a lot of developers, you can still draw upon it, and the earlier methodologies and notations, if you use it when it's beneficial. If you want slightly more visual class/entity relationship diagrams (visual association role multiplicity, and generalization triangle where it belongs :), you can use OMT. If you're doing concurrent and hierarchical state models, there's UML or Statecharts. Never underestimate the power of an old-school DFD for talking about processes and data flows in a way that all stakeholders can understand and reason about. And everyone gets old-school control-flow flowcharts for steps/branches/loops. And you can even explain event trace diagrams to any stakeholder, if you walk them through the important real-world example, and they see it as worthwhile.
Based the recent carpet-bombing of UML comments on HN, I have a new theory about UML, and it's no longer that dotcommers have the strength of opinion that can only come from narrow experience (nor that the barrage is an accident of what I call blog-arbitrage)... :)
When Java first came out, it was one of the coolest things to be using. Then Java became an "enterprise" thing, and became very different. I'm wondering whether enterprise-sales-capture is what happened to UML.
Maybe the dynamic is IBM trying to sell enterprise products and training, orgs doing enterprise development wanting to have documentation and process standards, orgs mandating UML, lots of developers going through UML training, developers seeing UML as a checkbox expectation/requirement (like TPS cover sheets, rather than as a tool they find useful), etc.?
And that dynamic has driven the evolution of UML, as well as the examples-in-practice to which most developers have been exposed?
FWIW, even if UML has gone in a direction that's not applicable to a lot of developers, you can still draw upon it, and the earlier methodologies and notations, if you use it when it's beneficial. If you want slightly more visual class/entity relationship diagrams (visual association role multiplicity, and generalization triangle where it belongs :), you can use OMT. If you're doing concurrent and hierarchical state models, there's UML or Statecharts. Never underestimate the power of an old-school DFD for talking about processes and data flows in a way that all stakeholders can understand and reason about. And everyone gets old-school control-flow flowcharts for steps/branches/loops. And you can even explain event trace diagrams to any stakeholder, if you walk them through the important real-world example, and they see it as worthwhile.