4 ms·
2 reasons UML died: 1. Developers don't pay the kind of money they once did for development tools. Many don't pay anything at all. Those that do pay money typi
by taylodl 6y ago
2 reasons UML died:
1. Developers don't pay the kind of money they once did for development tools. Many don't pay anything at all. Those that do pay money typically only pay for an IDE (JetBrains or something like that).
2. The lack of financial incentive from (1) makes it so we haven't seen and likely will never see a round-trip UML tool - which is what's badly-needed to make UML an actual productive tool. The article mentions this. That's really too bad because such a tool would be worth its weight in gold - but good luck getting anyone to pay for it.
That's just where we are at the moment as an industry. Worse is better. Especially if worse is free (as in beer).
- dcolkitt 6y agoI disagree with the premise, because the major tech companies are so good about releasing open source developer tools. For example a unit testing framework is a really important developer tool. And we have great unit testing frameworks because Google has the firepower to invest in Googletest for its internal developers, then released Googletest to the world. If UML was really productivity enhancing, I'm pretty sure Google would be using it. Even if it had to build it from scratch, a 1% improvement in developer productivity would easily amortize their cost to build a fantastic, open source UML tool.
- taylodl 6y agoMeh. The industry has spent the past 15 years preaching "emergent architecture and design." The fear of BUFD (big, up-front design) has shifted the pendulum to the opposite extreme: little or minimal design. So here we are. I still think there's a lot we can do with CASE (computer-aided software engineering) - just not in the way we envisioned in the 80s and 90s.
- dcolkitt 6y ago> I still think there's a lot we can do with CASE (computer-aided software engineering) I'm pretty biased towards minimal upfront design. At least of the formal variety. But I'd like to make sure I'm not missing some low hanging fruit for easy improvements. Do you have any recommended reading for what you're talking about w.r.t. to CASE?
- taylodl 6y agoNo - the industry abandoned CASE in the 90's and the pendulum swung back the other way. I worked for a company in the early 90's that bought into case hard. I never thought CASE was about the tool writing all your code - but they sure did! What a nightmare! I'd like to see CASE used to capture big-picture items, major information flows, configuration management handling and the like. I'd like to see UML diagrams dynamically generated from the underlying model. Utilize a query language to allow me to select a class and see what all it derives from and see what it interacts with - graphically. It's another way of interacting with a code base. That's the stuff I'd like to see us get to.
- rswail 6y agoA "round-trip UML tool" is actually impossible, except for in very limited circumstances. UML itself doesn't provide enough detail to completely develop the code, and the code doesn't provide enough model hints to completely develop the UML. When there is enough detail, the diagrams become unreadable and the code becomes unmaintainable. So every "round-trip" details are lost. People have been trying to solve this problem generally for 40 years. It's a lost cause.
- taylodl 6y agoWhen I left the UML world 15 years ago what was being worked on was the model. Not everything in the model has to be expressed in the diagram(s) - that simply makes the diagrams unusable. The problem is UML "grew up" being diagram-based, which can't be round-tripped. Too many people rejected the model approach and the two factors I identified were then able to kill it.