16 ms·

Why UML “Really” Died

• intrasight 6y ago
  The "real reason"? MSFT was making too much money selling developer tools. If you automate app creation from specs (totally doable with UML for most CRUD apps), then it would have greatly impacted Microsoft's revenue.
  • AlexTWithBeard 6y ago
    UML has died, because any attempt to build an application automatically from UML led to endless discussions about association vs. composition and generalization vs. implementation.
    • slowmovintarget 6y ago
      Nah. The real reason was that framework evolution outpaced the ability of Model Driven Architecture tools to adapt to changing technology. I know, I used to work on one such MDA tool. It first started with the assumption that you want to generate a J2EE application. By the time the code generation was "good" Spring and Hibernate came along and simplified things to the point that it was easier and faster to "just code." Turning UML into executable code could be done in one of two ways. Transform one high-level model into an implementation-specific model and generate code from that, or, create a UML VM that could run the models directly. The latter would have been the correct solution, and still would be more complicated than it's worth. Use UML for communication. It's still good at that.
  • antonvs 6y ago
    Many companies tried to automate app creation like that. The entire CASE industry mentioned in the article was working on that. Not one of them produced anything worth using. It was nothing to do with Microsoft. The real reason that UML died is that it was a solution in search of a problem that it could actually solve. It was one that had a lot of appeal for people, so it took longer to die than it should have. But it died because in practice, it was largely useless.
    • deleted 6y ago
      [deleted]
    • intrasight 6y ago
      CASE is a very 1990s term - definitely deprecated. UML is awesome IMHO and I've used it on every CRUD app that I've built. I am saddened about it's lack of widespread use.
      • antonvs 6y ago
        The point about CASE is that there was a whole segment of the industry focused on addressing this problem, and it basically went nowhere. Today there are a zillion CRUD generator tools, most of which don't use UML. It's not difficult. Many people who've worked on CRUD apps have probably written some autogeneration thing themselves at some point. Automating some boilerplate code generation doesn't solve any challenging problem in software development.
  • willeh 6y ago
    Can't tell if you're joking but one of the selling points of Microsofts paid versions of Visual Studio used to be good support for writing classes using UML. Microsoft is the O.g low-code company spending most of the 00s making people do things in diagrams and form builders of different kinds.
    • intrasight 6y ago
      Partially joking. But really - MSFT has no incentive to reduce the required dev head count by tenfold.
      • rk06 6y ago
        they do. MSFT does not have monopoly on software. they compete with others. and have incentive to make life easier for their customers ... to destroy competitors
  • mikestew 6y ago
    You base this theory on...? Because I worked at MSFT at the height of the UML craze, in the Developer Tools division to boot, and the "DevDiv must make money"[0] mandate didn't come down until after the industry had collectively decided to move on from UML. Additionally, who do you think was going to stand ready to sell you the tool that "automate(s) app creation from specs"? Ever see a copy of VS 2003-ish? Conspiracy theories are fun, but the "real" reason is in one of the several articles floating around HN that past few days. Mainly, it was a disorganized mess that no one was going to build tools for. Then IBM got hold of it, then... [0] Previously it was, "we don't care if it makes money as long as it supports the Windows platform", hence the "developers, developers, developers" from Ballmer that folks like to dunk on. I was a grunt in DevDiv, so take it all with a grain of salt.
    • intrasight 6y ago
      Not a theory. I've heard it from MSFT product managers. > stand ready to sell you the tool There are a few - they've never been from MSFT
  • asplake 6y ago
    The money motivation isn’t that relevant but there’s some truth here. I used to work for a CASE tool company and I have long attributed their decline to the rise of IDEs and other programmer productivity tools. And not a bad thing either.
  • Bigpet 6y ago
    a spec precise enough to describe an "app" is a program. A person who creates such a spec is a programmer.
• cryptica 6y ago
  It died because big tech companies realized that their real customers are reserve banks; big tech companies are being paid for job creation, not product development. UML allows companies to build high quality software faster so it destroys jobs.
  • kstrauser 6y ago
    If UML did any such thing, IBM would be a trillion dollar company by now.
  • dragonwriter 6y ago
    > UML allows companies to build high quality software faster so it destroys jobs. Multiplying per-worker output in a field whose output isn’t limited by capital or raw materials doesn’t destroy jobs, it creates them.
    • rswail 6y ago
      UML has never done anything of the kind. I've never read any case studies outside of marketing that claimed that UML increased software quality in any concrete and measurable way.
      • dragonwriter 6y ago
        > UML has never done anything of the kind. That may be true, I’m just saying even jf it did, that wouldn't make it a job killer but a job enabler. The whole reason computing is a growing field is it keeps inventing ways to multiply its own output. If that caused the field to shrink, the progressive move from punch cards to IDEs would have destroyed the field.
    • cryptica 6y ago
      The kind of software which creates more jobs is not what I would call 'quality software'. Quality software gives people more free time, it doesn't consume more time. The fact that most people can't see the difference today is disturbing. It's a sign that we are trapped in an inefficiency mindset. We're always looking to solve problems in ways which create more problems instead of solving problems once and for all and then focusing on different problems.
• jokoon 6y ago
  UML is still taught in universities here in france. It's like the mafia of abstraction-oriented, ivory tower developer who just explain the software but never write code. I guess one upside is that developers know how to make diagrams. Which is good.
  • ridethebike 6y ago
    UML is totally useless abstraction and all until you somehow need to explain your architecture to 30+ developers/architects on the call.
    • jokoon 6y ago
      "architecture"? A simple diagram with components and how they communicate is pretty explanatory if you want a bird's eye view. UML seems to try to be too specific and detailed when it comes to relationships, inheritances, hierarchies, etc but it's often just unnecessary, because every language/API/framework have their own way of dealing with details. Not to mention that UML is often poorly specified and developers will not really respect the UML spec. It's like math, there are dialects. Programming language are better just because they have a proper parser that will verify correctness. It's hard to understand why one would verify the correctness of an UML diagram.
      • ridethebike 6y ago
        It does not have to be fully correct UML diagram. But knowing the difference and being able to draw more or less accurate high-level sequence/flow/component diagram is vital skill for skilled developer. >> Programming language are better just because Programming language is usually poor choice for explaining design of system
  • danpalmer 6y ago
    I was taught "UML" at university (UK, 10 years ago). I say "UML" because while that was the name given, we probably only had a few hours on it in my entire degree, and it was essentially boxes and arrows, with class names and methods, and the basics of sequence diagrams. I think it was valuable. I suspect many engineers use simple diagrams in notebooks on a regular basis, and by introducing it very early in the degree it gave us another tool to help think about the code we were writing. It wasn't actually UML, but I think it's a good thing to cover at the beginning of a course.
• mtnygard 6y ago
  > programmers use “die” to mean “decline in relative marketshare”, not absolute marketshare. Lots of thot leaders bemoan how few devs understand really low-level systems anymore, but there are more kernel hackers in total than there were 30 years ago. They’re just a lower percentage of all developers. This is such a great point!
  • goalieca 6y ago
    UML is dying though. I remember being grilled during job interviews on OOP design questions with UML and all those obscure details. I hate it. But now even the embedded world is more about API contracts with system designs and data stores. Very informal boxes and arrows with random annotations have proven far more effective than a fully specified visual language.
    • kragen 6y ago
      Yeah. API contracts are real (and sometimes even formalized to one or another degree with TLA+, IDLs like WSDL, and various other tools); UML was a fraud: https://news.ycombinator.com/item?id=26959307 https://news.ycombinator.com/item?id=26959307
  • zozbot234 6y ago
    Wait, "thot leaders"? Lol, I don't think that means what OP thinks it means.
    • hwayne 6y ago
      …Goddamn it. I guess I'm an old now.
    • the_local_host 6y ago
      EDIT: Turns out it was not intentional, see below, now fixed on the post. (original): Given how well-written the rest of the article is, I have to believe that's deliberate.
      • 6y ago
• steerablesafe 6y ago
  My wife had to use IBM Rational Rose at her previous job. I have to say I'm glad I never had to deal with this kind of BS as a developer.
  • zwieback 6y ago
    When was that? I remember evaluating it in the late nineties. I was fascinated by the idea of roundtripping UML-generated C++ code but it took so much effort to generate the code I wanted I gave up quickly.
    • steerablesafe 6y ago
      Ugh, a year ago, they are probably still using it.
• lostcolony 6y ago
  'Culture Shifts' is the relevant bit. Orgs that realize a month's worth of planning to save a week's worth of dev work have realized UML isn't useful to them. Orgs that haven't don't think it goes far enough.
  • deleted 6y ago
    [deleted]
  • slowmovintarget 6y ago
    Let's not confuse the basic notation with the tooling and priesthood that grew up alongside it. Much like "Agile" there's still value in the small. Hashing out a class diagram that shows how the domain entities relate to each other can still be pivotal in communicating the intended information model in a design. Pre-pandemic, this would involve words, lines, and cardinalities on a whiteboard (boxes optional). Nowadays, a quick domain entity diagram in Whimsical does the trick. A sequence diagram can quickly communicate an expected interaction pattern. The point is not to specify anything up front. The point of UML was always to serve first as a communication tool. Have commonly understood pictorial notations that let you talk about the software you're building. When it was first invented, UML was aimed at "Unifying" how we diagram things. First, for books, and for the patterns movement. Even the heavy-weight Rational Unified Process was intended to be used in an iterative fashion. But it was constructed from a consulting mindset where you have intermediate steps of review and approval. Blaming UML for the heavy-handed process where "thou shalt specify everything in advance" is like blaming the English language for that crappy novel you wasted your time on. UML still has a place, IMHO, but only in that it helps you get over a few speed bumps on the way to helping your team produce working software.
    • spookthesunset 6y ago
      > When it was first invented, UML was aimed at "Unifying" how we diagram things. See but “unifying how we diagram things” isn’t a problem that needs to be solved. A good diagram on a whiteboard is more art than science. It is also something that is intentionally as low of fidelity as possible because you might blow it away and do something entirely different. There doesn’t need any “standard” for how to do adhoc diagrams. The minute you add “formal standard” to the process it gets slower when you want it to be even faster. If my whiteboard diagram had to adhere to UML... I wouldn’t bother.
• CoreFailure 6y ago
  > Traditional enterprises were the dominant software employers in the 1990’s, meaning that tech trends likely reflected their interests. That would be a good explanation for UML’s initial rise. Over the past two decades, though, software culture shifted progressively towards large tech-first companies and startups. Neither, historically, was the target audience of CASE vendors. Over time traditional enterprise starts borrowing from tech and startups vs the other way around, leading to the progressive decline of CASE in its extant niches. This I think was the real thrust of the argument. While UML's death may be exaggerated in many corners of the corporate world, so too is its life in representing our industry as a whole.
  • cratermoon 6y ago
    I'm pretty sure UML and RUP were in the Gartner Magic Quadrant in the early 2000s.
• dragontamer 6y ago
  Sequence diagrams are very useful. Flow charts and state diagrams are also useful but less so in my experience. If your inheritance structure is so complicated that you need a class diagram, you are probably in for pain... But class diagrams do their job for sure. I find UML useful as post-coding documentation. After you figured out how things work, you UML diagram your code to help explain the complicated parts. UML is also useful for talking with coworkers. As a 'sketch' don't try to get everything right, but coworkers often need to know what your plans are if they are to find work that won't conflict with your plan. I think another UML post was talking about sketch 'masala' graphs (throw everything into a touchy feely graphic that really doesn't say much). Being absolutely vague and nontechnical is an advantage in some cases, but not useful to engineers. UML, for all of it's faults, is precisely defined. Every symbol means something.
  • jablan 6y ago
    Sequence diagrams, as probably most other UML diagrams too, predate UML.
    • libria 6y ago
      Apparently it postdates UML too: there's a sequence diagram tool trending on the front page right now[1]. [1] https://news.ycombinator.com/item?id=26956728 https://news.ycombinator.com/item?id=26956728
    • cratermoon 6y ago
      I think there's only one kind of diagram that in UML that doesn't have a clear predecessor: the activity diagram. There's a reason it's called the Unified Modelling Language, after all.
    • dragontamer 6y ago
      The point of UML was never to "invent" new diagrams. The point was to unify all diagrams so that your arrows in one visual-language are compatible with the arrows in another visual-language.
    • jhayward 6y ago
• d_silin 6y ago
  To defend UML a bit, I found sequence diagrams really useful when designing or understanding complex interactions in a software system.
  • jablan 6y ago
    You mean Message Sequence Charts? :) https://en.wikipedia.org/wiki/Message_sequence_chart https://en.wikipedia.org/wiki/Message_sequence_chart
• toolslive 6y ago
  The push is gone? IE, the three amigos retired.
  • hwayne 6y ago
    I think the only one who retired during the early decline was Rumbaugh; as one person told me, "he got out while the going was good." Grady Booch left modeling later. Ivar Jacobson is still around, though now he pitches his Essence framework. I always got the feeling he was the least "amigo" of the three, which makes sense given he joined due to a hostile takeover.
• 3v1n0 6y ago
  Bah, the only time I was asked to do an UML diagram I was at the university. I ended up doing the coding, and using a tool that generated the UML from it, so that I could make it nicer. > Code first, design later "they" said Ah, ops... :)
• Delphiza 6y ago
  UML never died because it never lived. It was always a zombie kept alive by Rational Software doing a really good job of generating enough hype, and market share, to sell to IBM for $3.1 billion. Since Rational was sold in 2003, UML has just been lurching from one generation of engineers to another shouting 'braaaiiins'. Trying to discuss UML objectively without the context of who was selling what at the time is pointless. It was never a good enough method to live beyond being kept on life support by the marketers.
  • agumonkey 6y ago
    You forgot the omg thing. Quite a few efforts were made for their uml super set.
    • Delphiza 6y ago
      Yes. Lurching from one OMG committee to the next shouting 'braaaiiins' :)
  • ncmncm 6y ago
    This. Back then, anything that could be used to increase a manager's department budget could be the basis for a business. There was a job, "System Analyst", whose output was supposed to be stuff like that. Programmers were supposed to just code what the diagrams System Analysts produced said, and not try to think. There is still an ISO Standard for regular flowcharts, and lots of DoD contracts require delivery of ISO Standard Flowcharts, so there are tools to automatically generate flowcharts from source code, which are printed out, delivered, and dropped in file drawers in dusty warehouses. Every five or ten years ISO issues a new Flowchart Standard. It has been suggested that they issue a Standard that says any old blank sheet of paper meets the Standard, to save a lot of money on printing them out and storing them. It hasn't happened yet. It would not be surprising if there were a zombie ISO UML Standard, and contracts requiring software be delivered with conforming UML.
    • bluGill 6y ago
      The problem is system analyst is a useful job only if they don't have to worry about all the details of the helpers and incidental data field and can focus on the high level parts that matter. In the mean time programmers need to add those little helper classes as implementation details, and they instead of to spend a week doing some formal request to the system analyst for something that could be done in an hour if they were allowed to think. And of course programmers have to think anyway.
• 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 ago
    I 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 ago
      Meh. 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?
• maire 6y ago
  I asked my kids (all software engineers) this same question about a year ago. My daughter said it was because class diagrams became too complicated for uml. I used to use uml class diagrams when coming up to speed on a new framework. I tried to do this recently and it was a nightmare. I used to use sequence diagrams for my own code - but that is difficult to derive from someone else's code.
• coverband 6y ago
  This was actually more enlightening than I expected... Ultimately, I think it comes down to: "...software culture shifted progressively towards large tech-first companies and startups. Neither, historically, was the target audience of CASE vendors."
• dep_b 6y ago
  I still use it, just a few minutes ago actually. If there's a process that goes over multiple threads or actors, it's nice to have a sequence (?, that one with lanes). If there's a process that has distinct ways to change states it's nice to make a state diagram. Also you might like to have a diagram about your database before you build your database. Or one of those classic decision trees that everybody uses even outside of software.
  • cableshaft 6y ago
    I use a database diagram before I do anything in a new project all the time myself. It's a good way to start thinking about any data-heavy project. Inevitably there will be things I didn't consider and have to add while implementing but it's still a great first step. I'll even draw them on paper sometimes (it's just squares with types and column names inside and arrows pointing to keys on other tables, mostly).
• tosser0001 6y ago
  I worked for a company that was making a large CASE tool way back when and even at the time it felt like nonsense. Internally it never even crossed our minds to use it as a means of building the tools themselves. I remember bringing this up at one point during a company meeting and the CEO glowered at me like I was pointing out some inconstancy in religious theology. He spun some web of garbage about why it wasn't appropriate for our specific needs. I was young and realized only afterward that it was just not something you were supposed to mention there. It was actually fun to work on for a while and we sold a lot of product, but it eventually dried up along with the rest of that part of the industry.
  • agumonkey 6y ago
    Some IBMers told me they never used any rational modeling technique for any software. I wonder if this was the case everywhere in the company.
  • dehrmann 6y ago
    > Internally it never even crossed our minds to use it as a means of building the tools themselves Obviously, this doesn't apply to everything, but that's definitely a smell for product-market fit.
  • specialist 6y ago
    I had similar experience at a Semantic Web startup. > I was young and realized only afterward... If I could give young me any single piece of advice, it'd be "OMG STFU. Just smile and cash the check."
    • jsight 6y ago
      I'm curious how it relates to your startup. None of your data lived in a semantic db?
      • specialist 6y ago
        You'd've thought so. Persisted to SQL-Server. Early 2000s, so totally impractical. The CTO cofounder was not impressed by the UI guy asking out loud what every one was thinking. The fancy pants UI I was tasked to create wasn't even backed by a query language or path expressions. So dumb. I stayed just long enough to find another gig. PS- I did storyboard and wireframed a novel UI which resolved the graph visualization "paradox" (aka "focus+context"). It'd be perfect for neo4j & Cypher. I always thought I'd eventually circle back, if only to see if the idea had legs. Oh well.
• InfiniteRand 6y ago
  I still see UML as a blueprint in my industry (safety critical software), MagicDraw is one tool rising in prominence, Enterprise Architect is another. I definitely have seen a decline in UML for code generation. (I forget if the tools I mention have code generator capability but I generally don’t see them used if they do) Interestingly I have seen a steady uptake in model driven development with code generation but it tends to be in tools like SCADE or Simulink, tools that are not directly object oriented but are more traditionally model oriented (code generation wise I believe these both generate C code). I think one problem with UML as code generation is that the relationship between the model and the code can be constraining and many domain experts do not think in terms of classes and objects. By the way, I do like the concept of UML as generating a code shell that gets filled in and modified, anyone have any open source recommendations for that? Preferably something that can integrate with Java and Spring
  • rswail 6y ago
    Safety critical software is about limiting the available software constructs to known safe ones (eg the MISRA standard) and adopting techniques and tooling like TLA+ that can be used to prove correct behavior. Things like FMECA etc are techniques for safe software (and hardware). Diagrams don't replace that. OOP as a technique (at least stuff about classes and inheritance and polymorphism) doesn't replace that. OOP in terms of objects and messaging, with state machines are certainly part of safety software development. The leftover CASE tools like Enterprise Architect are now basically documentation engines and have very little to do with the actual software development process.
• motohagiography 6y ago
  Some of the resistance I have encountered from developers and engineering managers to writing sequence diagrams has been because it makes it harder for them to bullshit about what their code does, how it does it, and how complex (or not) it really is. When you put an abstraction over something its parts can be replacable and in non-growth oriented development cultures this is what people try to avoid. Essentially, resistance to abstraction is often resistance to being managed.
  • kstrauser 6y ago
    More charitably, sometimes it’s impossible to accurately sequence events until you’ve tried implementing a thing, especially so when a 3rd party is involved. We use a vendor’s API that’s very well documented, and if you asked me to chart how we’d use it based on those docs, it would be very straightforward. In reality, we (only halfway) joke that this vendor puts the “eventual” in “eventual consistency”. Like no kidding, it’s often up to 5 minutes between PUTting an object and being able to GET it back. This doesn’t violate any of their API docs at all, but you tend to think of CRUD apps as being either synchronous or having latencies of a second or two. This vendor never claimed to have be that way but I kind of assumed it, which is 100% my fault but still a bit understandable I think. So the actual sequence doc is much more complex with several stages of polling cycles. In fact, it's really a linearization of what's actually implemented as a state machine. If a PM had held me to a simple, linear sequence diagram, they'd be upset that what I delivered didn't look at all like what I'd promised, but that's because we didn't know everything important in advance and we didn't know that we didn't know that. Lessons learned, huh? I don’t mind diagrams for documenting what was actually done so the next maintainer can understand why things are a certain ways. I would enormously resist being made to write code to satisfy them in most contexts.
    • hwayne 6y ago
      > We use a vendor’s API that’s very well documented, and if you asked me to chart how we’d use it based on those docs, it would be very straightforward. In reality, we (only halfway) joke that this vendor puts the “eventual” in “eventual consistency”. Like no kidding, it’s often up to 5 minutes between PUTting an object and being able to GET it back. This doesn’t violate any of their API docs at all, but you tend to think of CRUD apps as being either synchronous or having latencies of a second or two. This vendor never claimed to have be that way but I kind of assumed it, which is 100% my fault but still a bit understandable I think. Funnily enough, dealing with a similar vendor is how I got my start with formal methods. Except in addition to 5+ minute latencies, if you sent a second PUT request during that time they _would start randomly deleting data._ Good times, good times.
• ridethebike 6y ago
  UML as "Language to depict diagrams + set of tools on top of it + unified process and all the waterfall-ish bureaucracy around it" - yeah, sure, it's dead in the sense barely anyone uses it in such form. UML as "Language to depict diagrams" - not so sure, I use component, state and sequence diagrams all the time (in both interview and main job settings).
• Rochus 6y ago
  > prominent people from the early days, including Grady Booch, Bertrand Meyer, and Ed Seidewitz What does Bertrand Meyer have to do with the history of UML? > they bought Jacobson’s consulting company and phased out OOSE. Objectory was a much better tool than Rational Rose; never understood, why they killed it. The most useful features of UML and RUP came from Objectory (Rose only had clouds and arrows at that time). > The Reasons The given reasons are not very convincing. I would rather say that once again an originally good idea was blown up to such an extent that only the cargo cult league was completely satisfied with it, and everyone else realized that once again the wrong problem was being solved with a lot of effort.
  • hwayne 6y ago
    > What does Bertrand Meyer have to do with the history of UML? Good question! While he wasn't involved with the standardization of it, he was one of the first major opponents, primarily because 1) was already a giant in OOP methodology, and 2) had a competing notation (BON). Also he was a real big stickler about "it's not really OOP if you're not using EIFFEL (tee em)". So he had a lot of firsthand knowledge of the early controversies and arguments and stuff.
  • rightbyte 6y ago
    I guess Objectory etc. was better suited for statemachine like systems like telephone systems. I.e. the tool is better at Ericsson where it was originally used than IBM.
    • Rochus 6y ago
      No, it was general purpose and the direct predecessor of the initial UML and RUP versions. Here is a summary in case you're interested: https://www.ivarjacobson.com/publications/books/object-oriented-software-engineering-1992 https://www.ivarjacobson.com/publications/books/object-orien.... Objectory was the name of the method, the tool and the company as well. The tool supported the whole development process with fully cross-referenced model versions for each phase, model integrated editors with a kind of transclusion (see https://en.wikipedia.org/wiki/Transclusion https://en.wikipedia.org/wiki/Transclusion), and a very powerful document generator; even round-trip engineering was supported. Unfortunately the tool vanished when Rational both them and you barely can find anything about it on the web.
• TorKlingberg 6y ago
  I wonder if git had a part in it. That UML doesn't have a good textual format, or really any standard file format, means it really doesn't play well with git. I remember IBM/Rational had some kind of diff & merge tool for UML, but it was horrible.
  • robjan 6y ago
    Plant UML was pretty widely used. The interface is very 2000 but it's still maintained.
  • slowmovintarget 6y ago
    It has a standard format, it's just unpleasant. (XMI is not for writing by hand.) There were other textual serializations in the various OMG standards. But you're representing a graph, which never works properly with line-oriented merge tools.
  • the-dude 6y ago
    This screams XML.
    • tannhaeuser 6y ago
      If you mean XMI that's XML indeed. But merely it using XML doesn't begin to describe its insanity. It has metamodels, meta-metamodels, ..., all described in OMG's "MOF", starting from the idea that OO principles somehow pass as formal method or logical framework, and ends in "Extreme UML", posing decision problems with unknown complexity/feasibility/decidability left and right. It's truly junior OOP zealotry going beyond its comfort zone. What's particular bad IMHO is that OMG/IBM managed to undermine completely unrelated and useful BPM modelling standards into the dead end that was UML, taking those down along with the nonsensical XMI, MOF, EMF, GEF.
      • the-dude 6y ago
        My CS education was in the right timeframe, but somehow I have been able to evade the UML rabbit hole. We did have a course on Object Oriented Databases, which would obviously take over the world. Except they didn't. And CORBA.
• spookthesunset 6y ago
  I mean, over my career, I’ve seen plenty of flow charts, sequence diagrams, boxes-connected-by-arrows drawings and such. I’ve yet to encounter anybody whose actually done a formal “by the book” UML diagram. They are just too formal for real world use. Auto generated ones provide both too much information and too little information to be useful. I’ve never encountered human generated ones. Probably because they too rigid. Maybe the problem with UML is it just didn’t solve any real world problem. Perhaps diagrams created by humans to be consumed by humans don’t need a formal spec. There is just too much variation to capture in such a spec. At least I think. Again, I’ve ever encountered a by the book UML diagram in my entire career. I’ve encountered plenty of informal diagrams though.
  • Corrado 6y ago
    I spent quite a bit of time in corporate America in the early 2000's and saw a lot of UML being thrown around. I don't think anyone actually used any of the diagrams, but they were certainly required by the "process". Fun fact, one guy on the team built hundreds of pages of documentation (mostly automated) including UML diagrams. We usually only used 1 or 2 pages of it downstream. He was famous for giving time back to the project. Come to think of it, maybe building in buffers in the project was his role the entire time and I just didn't realize it.
• mumblemumble 6y ago
  A nice list. Personally, I've always thought that "too complex" was the most essential reason. To really get the intended value out of UML (as opposed to, say, cell phone pictures of ad-hoc whiteboard flowcharts), you need to put a lot of time into learning all its intricacies. Doing it right is a specialized skill, enough so that you probably need to commit a single person to maintaining the UML diagrams if you want things to remain coherent. But that's a problem right there. Smaller teams can't afford to commit a person to fiddling with flowcharts like that, and, even on larger teams, the need to communicate with that person in order to make sure the charts stay up to date is a large effort. When I was at a Global 500 company, we had regular meetings with the UML folks where we'd go over the charts, they'd explain what everything meant - none of the developers had sufficient UML expertise to independently understand the diagrams beyond a rudimentary level - we'd explain where things had drifted away from the spec, and back and forth we'd go until it all settled out. And I don't know what purpose all of that effort served, aside from satisfying a rule that had been passed down from above. Developers never went back and referred to these diagrams. Like I said, we couldn't really understand them, so it was quicker, easier, and more accurate to just read the code or talk to each other. Managers were even less able to understand them, and knew that they were only accurate up to the last UML sync-up, which means they wouldn't cover work in progress, which is almost always the thing they're currently looking to understand. So they'd talk to developers. And maybe we'd have a meeting to bring each other to speed on how it all works and how that's working out, and how it needs to change. And maybe, during that meeting, we'd draw an ad-hoc diagram on the whiteboard while we talk. And maybe, if everyone thought it was sufficiently useful, we'd leave it up there and write "don't erase" next to it. And the fact that there was no formal specification of the visual language turned out not to matter, in the end, because the diagram never needed to be a formal specification in the first place; it was just a mnemonic device to help everyone remember what was discussed in the design meeting.
• rswail 6y ago
  CASE never met its goals. It was yet another silver bullet in the software industry that has been ongoing since the IBM 360. People point at NASA's software engineering as the gold standard, but what NASA shows is something that Charles Eames said "Design is about constraints". NASA's software environments are all about constraints. Mission constraints, hardware constraints, environmental constraints, all lead to software that is beautifully written and maintained within those constraints. The rest of the software world has tried to reproduce the process without understand the constraints. CASE, CMMI, Agile-with-a-capital-A, all are attempts by businesses to standardize and commoditize software development. But software is about abstraction. We layer concepts on top of concrete hardware, then layer on top of that. CASE didn't work because the layers were in the wrong places and of the wrong things. UML was an extension of that. It was based on expecting software development to be like engineering and manufacturing, which are oriented towards components and commodification, not layers.
  • redblacktree 6y ago
    > "Design is about constraints". Indeed. I think most engineers would LOVE to have the kinds of constraints on their software that NASA has. The reason our code trends toward big balls of mud is that the requirements are ill-defined and constantly changing.
    • dublin 6y ago
      Welcome to the real world. As you point out, NASA lives in Wonderland by comparison. Good software handles real-world issues and changes without continual fundamental architectural redesigns. 95% of the bad software I've seen has been a result of not understanding one of two things, (which are really the same): 1) What the software needs to do to function in the real world, and 2) what the people who use the software need to do and how they think about their environment and the problems they need solved. It sounds trite, but in almost all cases, this really is all that separates great software from unbearably horrible software, and the astute observer will note that this has far more to do with understanding people than it does computers....
      • 6y ago
• Tempest1981 6y ago
  The article mentions text representations of diagrams. Has anyone had success with sites like https://sequencediagram.io/ https://sequencediagram.io/ or using "DrawIO" inside VScode?
  • cratermoon 6y ago
    Yes! PlantUML, DrawIO, WebSequenceDiagrams, even the dot file format of Graphviz, they are good. You can keep the source in the repo with your other code, and it is just another form of documentation (with all the caveats that implies). I gave up trying to use any visual tool to create the diagrams, though. Too slow, too clunky, too fiddly.
• ephaeton 6y ago
  We still use UML for illustrative documentation purposes leading the prose, sequence diagrams, state machines, activities. We barely ever use class diagrams. We don't draw, we let PlantUML do that. We only use UML because, well, PlantUML outputs those diagrams. If its output were non-UML sequence diagrams, state machines or activity diagrams, we'd be using that for documentation purposes. That's why I whole-heartedly disagree with "At best you’ve got a cumbersome system that’s significantly worse than using a graphical editor" from the article. I'll take succinct text over your graphical editor any day of the week, and my colleagues agree with me. Anyways. All hail plantuml ;)
  • jayd16 6y ago
    Yep. UML is meh but state and sequence diagrams can be good. Besides plantuml there's also the very similar mermaid which will work in gitlab markdown and show up in the browser.
• booleandilemma 6y ago
  UML died because people just want to open up draw.io and put down a few boxes and arrows, and they don't want the mental overhead of having to use a formal language for doing this.
  • AnimalMuppet 6y ago
    You start with an informal idea of what the program will do and how it will work, and you proceed from there to something formal (at a minimum, by the time you get to the code). Along the way, diagrams are useful for refining your own thinking, and for communicating with others. So I think what you're saying is that people want those diagrams to be on the informal side of the formal/informal divide, and UML tried to put them on the formal side. And that didn't work, because on the informal side, a diagram can communicate the general idea quickly. But on the formal side, diagrams are very tedious to produce in the detail required for a formal design, and even more tedious to edit to keep up to date as the design evolves. UML died because diagrams work better for informal rather than formal communication. I think that explanation fits rather well.
    • kragen 6y ago
      UML died because diagrams work better for informal rather than formal communication. I think that explanation fits rather well. That would be a great surprise indeed to mechanical engineers, chemical process plant engineers, electricians, analog circuit designers, machinists, architects, PureData livecoders in nightclubs, and many other groups of people. UML's problem wasn't that it was visual. UML's problem is that it was a fraud: https://news.ycombinator.com/item?id=26956298 https://news.ycombinator.com/item?id=26956298
  • sumtechguy 6y ago
    Then add in 'agile'. Which for some people seem to translate into just throw some code down and work out the details later. Oh then keep your docs up to date (many devs detest doc work). Then add in the cost for a RR seat (wasnt it like 20k per dev at one point?). Then add in the agile is a strict set of rules people (5 stages before story creation) while you were getting your UML just right for your story we finished the epic and the user signed off already. A few boxes on a whiteboard and some lines usually is more than sufficient for many things.
• stephc_int13 6y ago
  This is anecdotal evidence but I think this is not an isolated story. In 2001 I was working as real-time/embedded software engineer in France, our project was still running on old hardware, mostly C and asm on 68k. One day before the summer vacations we were asked to come and see a full-day presentation of the future. The presentation was made by an other team, working with embedded Java for microchips and ATM, UML and Rational was at the center of everything. It was so unreal I had a hard time staying calm. It was the day I decided to switch career, and that I would quit on the spot if they forced us to use anything as awful as those "methods".
  • martijn_himself 6y ago
    If UML is useful at all, it is maybe in enterprise software / modelling business processes and even then I had hard time justifying it, so I can completely understand your reaction when it comes to real-time/embedded software.
• tragomaskhalos 6y ago
  Hmmm. Not-so-fun memories of those times: 1. Doing sequence diagrams in Visio, sans any kind of plugin that understood them; cue realising you'd missed a bit out and having to do an awkward group-select and drag a load of gubbins down the page to make room, then finding you'd missed an arrow or something .... 2. CASE tools that promised round-trip engineering .... so my Hovercraft contains many Eels, and I have that in my nice UML diagram, but how is that going to translate into pre-generics Java and back again? Spoiler - it isn't 3. Being given a massive wad of UML diagrams by a client, but the author had actually done all the contains relations as if it was a data model diagram, so all the relations were backwards - i.e. Eel diamond-arrow Hovercraft, because that's how the foreign keys would be done. How to break this kindly ...
• victorhook 6y ago
  As a CS undergrad taking a course in Software Engineering, where we are currently studying UML, I wonder what the alternatives are? What tools/methods are used in practice, today, instead of UML?
  • bradstewart 6y ago
    In my experience, the broad concepts of UML are applicable and used in real-world engineering/design. By "broad concepts" I mean something like "draw boxes for classes/objects with arrows pointing to related other objects". Thinking about systems as state machines, sequences, entity relationships, etc is useful. But the rigid details of specific lines styles, arrow types, etc are very rarely used.
  • cratermoon 6y ago
    You're fine. Draw some useful diagrams. Sometimes, generate useful diagrams from parts of code you're having issues understanding (Doxygen, with a little help, can do it). Do not try to create a diagram and generate code from it, and definitely don't ever attempt round-tripping your code and diagrams. Use the syntax, don't get caught up in the tooling.
  • jacobsenscott 6y ago
    Sometimes it seem like "nothing" is used today. People just start writing code. This actually isn't a bad way to go 70% of the time. But if you find yourself struggling it might be time to step back and think it out with some informal UML sketches. Nobody uses "formal" UML anymore. The main risk of UML is it can lead to overly complex designs - it is so easy to add another box and arrow, to make it match a GOF pattern, etc. As for what we use here in practice today - pairing and talking out ideas sometimes with informal UML sketch, and test driven development.
  • krasicki 6y ago
    Design a notation based on existing norms to whatever specificity you deem adequate). I like process boxes with four sides. Left side takes input, the right spits output. Top side takes constraints, rules, or links to specs. Bottom accepts triggering mechanism, temporal/sequential constraints, polling, and other controls. Complex Processes get decomposed down to autonomous objects that can be programmed as desired. Many of the stripped down existing iconic notations can be similarly instrumented to be useful. Be your own guru.
• tnolet 6y ago
  I started my career at CMG, a big consultancy now called Logica. They were BIG on UML and Rational Unified Process. I had no clue what I was doing so I gobbled it up. "So THIS is how you make software, ahaaaaaaa!" After leaving CMG I have never, ever seen it used in the wild by any remotely successful company or team. I would say it is a clear red flag even. Sequence diagrams are the only thing I sometimes use to get a grip on how APIs should talk to each other or how flows between integrations should be.
  • tragomaskhalos 6y ago
    Logica no longer exists - gobbled up by the Canadian company CGI in 2012.
    • tnolet 6y ago
      Ah right that's true. Their stock had tanked very, very hard I remember. My option plan was worth zilch. I left in 2003 already and didn't really follow it after that.
• nickbauman 6y ago
  The reason why UML died is muuuch simpler. It simply promised what it could never deliver. Unlike what UML is trying to simulate, which is an architectural blueprint, a UML model of a system cannot be verified for correctness. But a blueprint can be verified; You can tell "that proposed bridge" will hold "so much traffic and wind" by studying the blueprint.
  • hinkley 6y ago
    UML has the same problem as every other graphical programming language: nobody has solved the problem of diffing two versions of the 'code'. Most code is verified for correctness by human eyeballs. I think many of us underestimate how important the 'diff' is with respect to incremental reasoning, which we do more often than not to keep the costs down. Once in a while we 'audit' the system, considering the model as a whole, but more often than not we are thinking in terms of deltas versus previous expectations. Whoever actually solves the visual diff problem, I would be happy to see nominated for a Turing award. It's that big of a hill to climb.
• cratermoon 6y ago
  This discussion and the one it references, previously on HN[1] conflate UML the diagram syntax (which remains useful) with UML as visual CASE tool. The latter never really lived, any more than any other "programming without writing code!" tool lived. The former is alive and well, after shedding a lot of the fiddly details and requirements that the bits of the diagram be expressed in low-level details. Case in point: association vs aggregation vs. composition in class diagrams. All three express a similar idea by having a line joining the two classes: this class and this other class work together. But for aggregation and composition, one end of the line is supposed to have a diamond. Which end? Should the diamond be open or closed? What about multiplicity? Which end of the line has the number? It depends, sometimes both. But all that detail, while sometimes useful to people looking at the diagram, really only matters for the benighted folks who try to make their UML diagrams input into code generators. Forget "UML is dying", accept that CASE tools will never be more than fancy and fiddly code generators, and use the general ideas around diagramming, including some UML syntax, as a way to communicate among team members and stakeholders who are sufficiently technical. 1. https://news.ycombinator.com/item?id=26934577 https://news.ycombinator.com/item?id=26934577 p.s. Don't use quotation marks for emphasis. Ever. It's wrong.
  • ahelwer 6y ago
    I think the author addressed this? > The other ambiguity is what we mean by UML. First of all, UML consists of over a dozen different diagram types. I still see people regularly use sequence diagrams. Second, there’s many different ways people use UML diagrams. Martin Fowler, a prominent figure in both the UML and Agile worlds, identifies three types of uses: sketching, blueprinting, and programming. Then they talk explicitly about blueprinting.
    • cratermoon 6y ago
      Yup, and the only UML book I ever bought and used, UML Distilled, was written by Fowler and Kendall Scott. It's a slim book, and notably says little to nothing about UML as a CASE tool. There's definitely nothing about any specific program for generating code, and not much about generating diagrams from code, either.
• avodonosov 6y ago
  Ha-ha, just now I am sitting writing documentation and use UML for illustrations. No-one told me it's dead. I must say, the drawing (CASE) tools have always been missing even very basic elements of UML. I learned UML in the year 2000 by reading the full "The Unified Modeling Language User Guide" book by Booch, Rumbaugh and Jacobson. Every time I tried to create a diagram during the years, after envisioning how I would express the idea with UML I was blocked by the tool not supporting the notation elements I needed. Like for communication diagram the tool did not support the iteration notation for message numbers, only simple numbers (what tool was it? maybe even Rational Rose). Or qualified assignation (when association is a lookup by a key). I adjusted to not expect much from the tools and I think I know how to use UML to create useful illustrations - just workaround the tool limitation with a comment or build the notation element from basic boxes or use a less descriptive notation then I wanted initially. Not to say I used UML very much over the years, as I use it today I realize I forgot many things and need to refresh my memory. However, I see sequence diagrams used all the time. From time to time I see other diagrams. The tools like plantuml as well as the online utilities like https://www.websequencediagrams.com/ https://www.websequencediagrams.com/, https://swimlanes.io https://swimlanes.io and https://sequencediagram.org https://sequencediagram.org are flourishing.
• overgard 6y ago
  I think UML died because it was never that useful in the first place. If you want a high level design to get an idea across, a back of the napkin sketch is a lot quicker and less formal, and once you start getting into the formalities of UML it suddenly becomes more effort than it's worth, since you need tooling etc. It also implies a heavy OO approach, which isn't really going to fly with C hackers or functional programming enthusiasts.
• chmod600 6y ago
  Until we get some kind of lid on complexity, I don't think real engineering will happen. If any abstract box in your diagram can be arbitrarily complex, then it's not going to stay in that little box. It will develop tendrils into logging and error mechanisms, and start to find extra jobs it can do with extra connections to other components. Pretty soon the semantics of the box will be so complex that they can't be reproduced elsewhere, and you will have to use that box for all kinds of new tasks. I imagine a database was, at one time, just a little box on someone's diagram. Now it's Oracle Spanner RAC Mongo Hadoop and must be used by every line of code in the world to get anything done. That's why a diagram is useless (EDIT: useless as a prescriptive language, but still useful as a descriptive language.).
• danans 6y ago
  One point that a lot of these articles seem to gloss over, even in their discussions of changing software engineering culture, is that UML - used as a formal specification cast nearly in stone by a software architect - emerges from a time when the software architect was not very involved in the software implementation, which was done by programmers who received the specification. In this stratified approach, the specification had to be highly formalized and specific, since the architect had little role in the implementation - hence approaches like UML. For many good reasons, including the rise of bottom-up hacker and startup culture, and the need for flexibility/iteration between the design and implementation, we've shifted to a paradigm where the architect is also usually the programmer, especially at the early stages of the software creation process. The architect themselves usually writes the core functionality of the software. This is true even at big modern tech companies. Furthermore, "Software architect" is far less a distinct job description like it used to be, but now refers to the degree of responsibility an individual has for the software's structure and design, which usually correlated with experience and the project scope.
  • 908B64B197 6y ago
    The Architect-Programmer model was also meant for offshoring. It backfired horribly once "Architects" realized how precise they had to be with these cheap teams.
    • danans 6y ago
      > The Architect-Programmer model was also meant for offshoring. I don't think this is true. The Architect-Programmer model precedes offshoring by decades, even if it was repurposed to facilitate offshoring. It was the dominant model during the "Corporate IT" phase of the software industry (before the web/Internet took over), and was famously satirized in the classic movie Office Space and also in the Dilbert comics. It has older roots in traditional corporate structures that strongly delineate "corporate" vs everyone else. The word "corporate" in office culture even used to mean "distant, out of touch bosses in luxury offices", and still kind of means that in industries with similarly stratified workforces.
• juancn 6y ago
  UML is an artifact of trying to sell products as part of the Waterfall model of software development. It wasn't very useful even at its peak. It was Rational software pushing their process and CASE tools. It was an awful, inefficient and bureaucratic process that made it easy to write contracts about deliverables while delivering mostly no actual value to the customers.
  • krasicki 6y ago
    Agile is a refinement of Waterfall. I think of it as the white water rafting SDLC of waterfall. The minute sticky notes in swim lanes and informal diagramming were replced by heavyweight, middle-managers (-cough- "agile coach") - waterfall is back. Rational is one factor of many that brought IBM to its knees -(WARP-OS2) being a contemporary.
• jacobsenscott 6y ago
  There's a really nice "UML the good parts" within UML that is useful. Sequence diagrams, state diagrams, and class diagrams can instantly clarify a design. But go ahead and ignore the hollow vs solid arrows, dotted lines vs solid lines, etc. Those tend to be obvious from context. The main reason I don't use UML more is that there really is no good UML diagramming software. It is either way too complex (tries to implement the whole UML "standard"), or else it is a general purpose drawing tool (you need to painstakingly connect arrows to boxes, etc) UML was built for conference room whiteboards, and as a remote worker I haven't had a whiteboard in years.
• adverbly 6y ago
  Functional programming trends killed it imo. Map filter reduce make up a big part of the code I write and it takes longer to write the hard-to-read UML version of those than it does to write the actual implementation.
• specialist 6y ago
  Be me, mid 90s. Wannabe methodologist. Earnest, enthusiastic. Dismissive of OOAD/P criticisms. Attend OOPSLA '98. Spot break out session on Software Architecture. Featuring Grady Booch! Oh boy, I gotta go. Finally work up courage to ask my hero Booch "What is 'Software Architecture'?" Long, thoughtful pause. "'Software Architecture' is what Software Architects create." Poof. Bubble popped. FWIW, the Agile Methodology™ hype cycle is self same.
  • bluGill 6y ago
    I've heard this definition of software architecture that I like: "the art of getting right up front the things that would be very hard to change latter if you got them wrong". What those things are is different for every project. They can even change over time, but you need to get them right up front anyway.
    • specialist 6y ago
      That totally works. Thanks. Much later, I stumbled apon (paraphrasing) "architecture is the set of visible design choices" from the economics book Design Rules: The Power of Modularity. I long thought that book would become seminal, classic. Shows what I know.
• kragen 6y ago
  https://archive.fo/ElsFw https://archive.fo/ElsFw
• neilv 6y ago
  I'm not going to defend UML, but it's disappointing to skim the recent walls of UML headlines and comments on HN, and assume that these posts are going to determine what most HN people think about UML, modeling, CASE, etc. (This assumption I think is sorta analogous to how we knew waterfall and even spiral were hard, and that many teams would need help to deliver successfully... then someone told those teams they don't have to work that hard, if they instead operated more like situated action reactive agents instead of planning ones... and then the default impression became that people who did waterfall/spiral must not have been as enlightened as ourselves, and we have nothing to learn from them. :) I could yammer for hours on methods and tools, but I'm more passionate about other topics right now. I'll just quickly point out one barrier to uptake of UML... One of the barriers to the modeling methodologies was that many people didn't know how to use them, and so presumably didn't see benefit. That they didn't get it was obvious when you'd see diagrams that were simply wrong, or that expressed no information other than being a not-very-helpful transliteration of code. And a lot of the examples people saw also had this problem. A memorable epiphany I had was shortly after joining an R&D group for next-gen OO CASE. One of the senior people was describing some complicated unfamiliar thing we had to understand, and using an OMT diagram to do so, pointing to things on the diagram as he explained... and it clicked: I was understanding so much from a diagram, and we couldn't have gotten that from code. I then learned all the other modeling things, and set about to design an approach to make it practical to use them all sorts of places (roundtrip, methodology flexibility, better HCI, etc.). Then business things happened, maybe because Rational was locking in an industry shift with what was turning into UML, and so I instead went to work on Web and HCI&AI hybrids.
  • krasicki 6y ago
    This is an understated truth about most iconic notations let alone anything instrumented into a CASE tool. That is that the Agile movement introduced a meanness and immediate gratification factor into the very idea that modeling software was useful or necessary. Concepts as simple as an input arrow going into a process would enter from the left of a circle or box and the output would exit from the right were the object of debate and ridicule. Why bother? Skippy, the agile programmer, had already coded something up that happened to feature the end-users favorite color. Eye candy always trumps rigor and deliberate modeling of components. Formal notations didn't stand a chance.
• omginternets 6y ago
  I've never worked with UML, but part of me wants to like it. Part of this is a reaction to (IMHO) an excess of "agile" methodology and a corresponding lack of forethought. The more intriguing part, however, is the idea of subdividing the problem using visual formalisms, and diving down into code to formalize the trickier bits. I wonder if there's a clear boundary beyond which visual formalisms are no longer effective? I'm reminded of visual proofs in mathematics, and their reputation for being unreliable and misleading. It would be cool if we could identify a subset of cases where visual formalisms were (nearly) as rigorous as lexicographic ones, but nevertheless more intuitive.
• butonic 6y ago
  Back in 2011 we built yatta solutions as a startup around template based roundtrip engineering. UML lab would use templates to not only generate the source code from UML diagrams but also to 'parse' the code. I don't know the current state of https://www.uml-lab.com/en/uml-lab/ https://www.uml-lab.com/en/uml-lab/ because I left for other adventures, but if you are looking for a tool that can actually keep code and UML in sync give it a try.
• lowbloodsugar 6y ago
  On round-tripping, anyone remember Together-J? Realtime round-tripping between UML and Java.
  • jvreagan 6y ago
    Was going to find a place in here to comment on Together. I remember spending $1500k on a professional license circa 1999, and still think it was the best money I've ever spent on an IDE. Incredibly powerful for large-scale systems, and made large-scale, readable-code development fast.
• kragen 6y ago
  UML died because it was a fraud. The biggest UML proponents (sometimes including Rational) weren't promoting it for informal design sketching—for which it works well!—or even just blueprinting; they were promoting it for higher-level formal modeling and specification of system design and behavior, including especially software systems. Given such a formal model, the charlatans explained, you could find design errors earlier in the process and fix them before proceeding to implementation work, and you could rigorously verify that the system actually built fulfilled its requirements. These are very useful properties, and clearly such model-driven development could save a great deal of time and money. The problem is that they have nothing to do with UML's actual capabilities; selling UML as a path to this utopia was just a lie. Things like TLA+, Alloy, Coq, Hypothesis, and even JUnit can sometimes deliver on some of those promises, but UML can't. Hillel Wayne explains why in this newsletter: UML never had the formal semantics necessary to deliver these properties; its implementations were buggy, incomplete, and unmaintained; and it also suffered from the same kind of specification drift that leads to out-of-date comments and useless unit tests in common practice. So I think what happened is that some companies tried UML and the associated SEI CMM processes, found that the promises were a fraud, and abandoned those processes. Other companies saw that the companies in the first group were doing badly, so they tried other things. I seem to recall an ad (!) for Extreme Programming in Dr. Dobb's Journal about 20 years ago: it ridiculed SEI-style heavyweight processes with a cartoon of a sumo wrestler trying to run a marathon. And some companies did adopt Extreme Programming, which does deliver on some of those promises, a little; XP hammers pretty hard on, among other things, simplifying your design, formalizing all your system's requirements with unit tests and acceptance tests (though of course these are not very rigorous), and constantly and automatically verifying the system's conformance to those tests. And 02003 is about when XP started to take off, inspiring the adoption of fraudulent methodologies like Scrum that promised XP's benefits without its costs†, much as UML promised the benefits of formal methods without their costs. (XP is no panacea, of course; if you don't know how to design software, it can't produce a software design for you, and if you don't know how to program, it can't write the code for you, as UML proponents have frequently promised UML will do. XP's extremely weak formalization of requirements as pointwise automated tests just provides a feedback loop that tells you when you're digging yourself into a deeper hole and focuses your efforts, such as they are, on things that matter to the project. Today formal methods have advanced to the point that it's practical to do much better than XP, but that future is still not evenly distributed. Myself, I've barely managed to adopt Hypothesis, and productive use of Z3, TLA+, Coq, or even Alloy or miniKANREN is still beyond my skills.) — ⁂ — The kind of methodological swindle represented by Scrum and UML is not a new phenomenon. In 02005 I wrote '"Enterprise software" is a social, not technical, phenomenon', https://web.archive.org/web/20050812004045/http://lists.canonical.org/pipermail/kragen-tol/2005-April/000772.html https://web.archive.org/web/20050812004045/http://lists.cano... reflecting on my experiences writing so-called "enterprise software" and how its institutional imperatives systematically eliminate the feedback loops necessary for software development to actually create economic value; and in 01988 Dijkstra wrote EWD 1036, "On the cruelty of really teaching computing science", https://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1036.html https://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/E..., containing the memorable quote, 'Software engineering, of course, presents itself as another worthy cause, but that is eyewash: if you carefully read its literature and analyse what its devotees actually do, you will discover that software engineering has accepted as its charter "How to program if you cannot.".' Dijkstra had been skewering this kind of stupidity for decades at that point‡, but as long as the technically incompetent desperately seek answers to "How to program if you cannot" instead of dedicating the necessary effort to improving themselves, there will be no shortage of scam artists offering sham solutions like (the exaggerated claims that sold) UML. When they are forced to compete in the marketplace their companies will gradually lose to competitors managed by less ignorant people—Google, Apple, and Microsoft have long since buried Excite, Commodore, and Ashton-Tate—but UML remains very popular among defense contractors, since their profits are not contingent on operational efficiency or even producing working products at all. Let us hope that real formal methods are not tarnished by conflation with UML-style con jobs in the way that XP has been tarnished by conflation with Scrum. ______ † Scrum existed before 02003, and before 02001—Schwaber outlined it and named it in a 01995 paper that advocates a recognizable, if handwavy, version of that anti-intellectual abortion we call Scrum today—but essentially the Agile Manifesto in 02001 was a political strategy to hitch it to XP's rising star, and Scrum started to achieve significant adoption around 02005 as a result of that association. ‡ For example, in 01975 in EWD512 he commented, "Already many a large organisation is nearly crushed under the sheer weight of the illogical, unmastered complexity of its automatic data processing systems." EWD511 laments the lousy design of the 360 and IBM's attempts to promote it. EWD406, from 01973, contains further remarks on, especially, LANL and CDC after Cray's departure; EWD407 complains, "Simple souls have been made to believe that we have a retail shop in Philosopher’s Stones that, by magic, will cure all diseases," a theme that also appears in EWD406. In EWD483, in 01977, he thunders: Shortly after World War II, when [the students this speech was originally given to] did not yet exist, my physics teacher drew our attention to the fact that we had had the Stone Age, then the Bronze Age, then the Iron Age, and then, in the Netherlands at least, the Golden Age—but that the 20th century would go down in history as the Age of Incompetence (after which it became the order of the day). More than a quarter of a century later, I would like to add a modest extra: it will be recorded in history as the Age of Fraud. This is the widespread phenomenon which the little whitewash artist refers to as "wishful thinking", but to the infidel eye it is no different from ordinary, vulgar deception, namely the deception that consists of the desire to do something, being replaced indiscriminately through faith, and then the pretense of being able to do that thing. … Long is the list of organizations that, after having begun a task for which the competence was lacking, either went bust or managed to save their lives by saddling society with their inferior product, thanks to chicanery. This is a fairly precise description of Rational's business model, four years before the company was founded. (Corrections on the translation from Dutch would be appreciated; my Dutch skills are even worse than my miniKANREN skills.)
• dublin 6y ago
  Because Object-Orientation was always a real PITA and not particularly relevant to mapping to real-world problems, despite the fact that that was its initial selling point?
  • zozbot234 6y ago
    That's definitely true about OOAD. The whole point of development methodologies like RUP was that every step in design, from requirements analysis to large-scale modeling and actual implementation, should be structured around domain 'objects'. That kind of rigid approach does little to address the actual problems of modular software design; there's no reason to expect it to give satisfactory outcomes.
• fmajid 6y ago
  Great recap. I remember being invited by IBM to a round table with Grady Booch. The guy just mouthed platitudes worthy of an architecture astronaut, and utterly disconnected with reality.
• thehappypm 6y ago
  I enjoyed learning about UML in CS grad school. It was super tedious and arcane, but now in industry as a product manager, I realize that there's value in different types of diagrams. Not everything is a flowchart.