27 ms·

Has UML died without anyone noticing?

• sunstone 6y ago
  It was still born.
• BoDlulu 6y ago
  No.
• KabukiStarship 6y ago
  This is just false. People just need a better UML IDE, and to stop thinking you need 100% UML coverage. UML is supposed to save time, if it doesn't don't do it, when it does you're wasting time to not use it. UML is still the go-to for creating State machines. I use them all the time in software and computer engineering. I've been using StarUML myself for years and it's still usable with the unregistered free version, you just have to put cards behind the UML to block out the watermark. I can't recommend StarUML enough. If enough people start buying it they'll put out more updates, it's been years since the last update. Evidence UML is not popular right now. If you're trying to break up a project into work for a large team, UML makes sense. Most people are clueless of how to do Test Driven Development right. I personally start with use case scenarios, then write console tests with dummy users named after my UML actors. By writing the console test with mock JSON data, you can quickly build high quality apps. The problem is when you have to update your UML, it becomes a time sink. Really we should have IDE and AI tools to reverse annotate the UML models. And CV tools to turn drawings on backs of napkins into UML. I have not tried PlanetUML but it looks really cool, and it's my style. Comparative to StarUML, I would argue it's probably better for your creativity to type stuff out by hand but StarUML's CAD-like interface is very good. I personally run a startup that does pen-and-paper GitHub/Markdown integrations and I'm working towards converting my I am You Language (IMUL) to PlaneUML. It's competing with other products for attention though. I think that's the end argument about UML, it competes for time resources, I need help.
• throwaway931245 6y ago
  What is UML?
  • zozbot234 6y ago
    User Mode Linux. An old project that was in the same space as present-day Xen and KVM.
  • jbverschoor 6y ago
    Unused Mainframe Linguistics
    • jbverschoor 6y ago
      Luckily I have enough karma to afford these kinds of comments :-D I never liked the arrow-direction in uml
  • simonw 6y ago
    Unified Modeling Language: https://en.wikipedia.org/wiki/Unified_Modeling_Language https://en.wikipedia.org/wiki/Unified_Modeling_Language
• phoe-krk 6y ago
  Anectodal data point: no, it hasn't. I still use it in every project that we make at my dayjob, including system documentation, implementation proposals, communicating design choices to other people.
  • tyingq 6y ago
    That's what I tend to see as well. Used around documentation and drawings. Used much less in any context around real code...little code->uml, and almost no uml->code.
    • zozbot234 6y ago
      Doesn't Doxygen give you code-> UML structure and collaboration diagrams pretty much for free? It also supports a wide variety of languages.
• slim 6y ago
  No. I use it everyday. On paper. On white board. Whenever I want to think about (foreign) business logic, alone or in group.
  • domano 6y ago
    Like actual UML or UML-ish diagrams?
    • ozim 6y ago
      That is picking on the details. I think most of people were doing UML-ish diagrams anyway because unless you really have a use case for it it is just wasting time to go full "UML".
      • k__ 6y ago
        Probably a bit like REST. Seems obvious at first sight, then you get 80% right in 20% of the time, and don't bother to put in the last 80% of time to get to 100% understanding.
        • ozim 6y ago
          It is also like using fancy vocabulary. You might sound smart and all but most of people will think you are silly. Then there will be a lot of people who won't understand you and there might be more problems because of that misunderstanding. When you will make perfect REST API there will be someone who will not understand it and will just try things and he might make a big mess. The same if you will create beautiful, perfect, UML diagrams. If no one else is proficient using them and it is only you. There is no advantage of working this way.
      • MAGZine 6y ago
        i don't think it is. the article isn't saying the diagramming is dead. it's saying uml is dead. using boxes and arrows isn't uml (full uml) and as you say, it's wasting time to go "full uml," which is why it died. diagramming will live on, even if inspired by uml.
• seattle_spring 6y ago
  It was dead when I learned it in college in 2006.
  • deleted 6y ago
    [deleted]
  • Snetry 6y ago
    Good to hear that considering its still taught in at least one school
• azeirah 6y ago
  Standardised UML was never something for me, sketching diagrams loosely inspired by UML definitely was.
  • adjkant 6y ago
    This is the real answer. The effects of UML will live on forever, but a formal language for it has been dead for a long time in common use, though some of course will still use the exact formality. The value of UMLish things is just visually diagramming data and systems. Boxes with arrows and some data inside is typically enough to do the trick. Lucidchart is thriving despite many not actually writing explicit UML on it.
    • billfruit 6y ago
      Why is this sentiment so prevalent. I'm thinking more and more that simplistic and vague informal diagramming is a great source of confusion. UML, specifically statecharts capture a lot of behaviour unambiguously, though it is hard to draw by hand (due to its hierarchical nesting possibility, so some kind collapse/expand system is required to draw them in a sane manner).
      • MsMowz 6y ago
        In my experience (startup product development), product requirements and constraints are constantly shifting in order to support new use cases. In my practice, that has translated into only formalizing specifications after the fundamental needs of a system are set in stone, which is usually after release. When I’ve worked on contract-based projects, it’s been much easier to formalize beforehand, but I suspect most developers on HN are involved in active product development.
        • billfruit 6y ago
          Thats true, but at least before implementation, the behaviour to be implemented should be known to some extent. UML Statecharts remain a good method to document behaviour.
• ncann 6y ago
  In my experience, any attempt to describe/document/plan a system using UML inevitably turns into an outdated mess that no one is willing to waste time on updating. Eventually it becomes worse than useless since it contains objectively wrong information.
  • Someone 6y ago
    I don’t think the “using UML” phrase is significant in that statement. It seems weird that “No one is willing to waste time” updating diagrams, yet everybody who encounters a new large code base starts drawing diagrams. It’s not clear to me whether making it easier to update diagrams or making it required (say by having the diagrams be part of the source code, without which the code won’t compile. There have been several attempts writing such systems, but none has become popular) will help there. Maybe, the act of drawing such diagrams (as opposed to looking at them) is essential for learning a code base.
    • Kwpolska 6y ago
      > It seems weird that “No one is willing to waste time” updating diagrams, yet everybody who encounters a new large code base starts drawing diagrams. [citation needed]. I got a new job fairly recently, we’ve got a massive codebase, and I never had the urge to draw any diagrams. (We’ve got zero diagrams as part of our docs as well.)
    • ajuc 6y ago
      > yet everybody who encounters a new large code base starts drawing diagrams I draw a lot of diagrams when exploring code, but they are almost never uml, because usually I look at code searching for a particular information, and only draw what is relevant to that search with varying level of details. If I was to draw everything (no matter the format) - it would become a huge mess with signal-to-noise ratio very close to 0, at that point I might as well just read the whole codebase.
    • Viliam1234 6y ago
      I usually start drawing diagrams because the existing ones are difficult to read. This is another problem with UML in practice, that drawing diagrams is a skill, a bit similar to writing code in the sense that it is possible (and quite frequent) to have "spaghetti diagrams" with dozens of classes on one screen connected by long zigzag lines you need to carefully trace by finger. The solution, as usual, is "divide and conquer", where you create a separate diagram for user management, another diagram for invoices, yet another for... whatever the application does. Okay, people do it partially, like they split 100 classes into two diagrams with 50 classes/tables each, but good design would be more like 10 diagrams with 10 classes/tables each. Another problem is that the UML language cannot capture things specific for the project. For example, suppose that 80% of your classes have fields like "date_created", "date_modified" etc. How are you going to handle this? If you write those fields everywhere, you get lots of repetition. If you don't write them, you miss a potentially useful information. With an informal diagram language, you could create a project-specific convention, for example a small clock icon in the corner would imply presence of "date_created" and "date_modified" fields -- and the icon itself would also be explained somewhere. A bit like graphical domain-specific language.
• INTPenis 6y ago
  Actual engineers still use it. Not the ones we started calling engineers because they know a bit of Linux and kubernetes. I actually saw a kid a few years ago with a huge UML book, a student at the local uni. Being self-taught I had no idea what it was so I had to look it up. I can't even come close to working with those actual engineers, I just mess around in Bash and automate stuff you can learn for free using open source.
  • nexuist 6y ago
    Not sure why you included the necessary gate-keeping. If you do the same things engineers do, you are an engineer. You may not be a good one, but you still count. > I can't even come close to working with those actual engineers, Then how do you know they still use UML if you've never been around them?
    • lainga 6y ago
      >If you do the same things engineers do, you are an engineer A very American perspective! https://en.wikipedia.org/wiki/Canadian_Council_of_Professional_Engineers https://en.wikipedia.org/wiki/Canadian_Council_of_Profession...
      • nexuist 6y ago
        OP said engineer, not licensed engineer :)
        • 8note 6y ago
          The Canadian perspective is that all engineers are licensed engineers. An unlicensed engineer is illegal
          • Graffur 6y ago
            I kind of wish software would just adopt 'developer' worldwide.
    • 6y ago
• detaro 6y ago
  I don't think it'll die entirely anytime soon, but certainly it has lost in mind-share - especially in the fully by-the-book way. Vaguely UML-like adhoc notations are way more common, and will survive even longer. (And my interactions with people aiming to do it properly have involved more ambiguity than would expect from a good standard)
• TheJoYo 6y ago
  GitLab supported Mermaid.js rendering for a while but last I checked that was broken. That showed the most promise for a practical use of UML. I have no idea what that article is trying to get at about multi-dimensional diagrams. I can make masala in UML, there's literally nothing stopping me.
• darkerside 6y ago
  UML suffers from false precision. Nobody cares about most of the specific rules and grammar of the language because the output is designed to be generally readable by a lay audience. The time your spend making your diagram compliant with UML is better spent making and remaking good general diagrams.
  • billfruit 6y ago
    Is there a general diagram with the expressivity of UML statecharts?
    • ajuc 6y ago
      almost uml statecharts that ignore some rules where they don't matter
    • zozbot234 6y ago
      Petri nets, especially if extended w/ hierarchy. These seem to be more elegant and expressive than plain FSM's as extended in the UML approach.
    • tyingq 6y ago
      Graphviz dot maybe?
  • Daishiman 6y ago
    Also the level of detail that UML demands always turns out to be imprecise once coders end up implementing specs. So it's a place where enough formality is required to be a PITA to model but where it falls just short enough of the specifics a programmer will need once they get to actually building out the product.
    • lordnacho 6y ago
      I was gonna say just this. If you are able to specify how the objects are related, why not just code up the skeleton? Similar issue in UI design. Why draw up the mock when you could just make a static webpage?
• k__ 6y ago
  I mostly use it to understand code-bases. It's a bit unwieldy, because of its OOP origins, but it helps me to visualize how code relates to other code and how software behaves at runtime.
• slver 6y ago
  UML was propped up (and still is) by universities, but it was never big in practice.
  • azhenley 6y ago
    I think it was made big by Rational and some bigger name consultants.
  • k__ 6y ago
    I think, some diagrams are nice tools, but the way we learned it at university was overkill. We had whole semester long classes solely focused on designing systems with UML. In my job I never did this ever again.
• yrgulation 6y ago
  In theory, UML diagrams sound good. In practice, having to maintain them is PITA. I quickly abandoned them as soon as i went above 10 classes, which even a basic OOP codebase will exceed quite early on.
  • k__ 6y ago
    Yes. It's nice to ge an overview, but I don't bother to maintain these diagrams.
• TruthWillHurt 6y ago
  It's alive and well in enterprise projects where Solution Architects need to micro-manage frequently-replaced, Acceptance-Criteria-driven, non-thinking contractors.
• andi999 6y ago
  I think the big hope for UML was code generation, so UML->code, but the problem was, when manual fine-tuning of the generated code was needed, there was no functioning process of code->uml.
  • superjan 6y ago
    Why would I spend an hour on buiding a diagram to generate code if I can type the same code in five minutes? I can read both. This is from real world experience with Rational tools.
    • Nasrudith 6y ago
      I suspect the idea was to lower the skill ceiling to make it accessible to non-programmers or more cynically in a belief it would cut labor costs. It doesn't work out that way but overspeccing the wrong details is a persistent temptation, perhaps related to psychology of the leaders for reasons similar to micromanaging.
      • andi999 6y ago
        Either that, or probably thinking about huge systems with uml diagrams in the size of the last supper.
  • Marazan 6y ago
    Together/J made a really good attempt at it. So good that Borland bought them up and shit canned it.
• radiator 6y ago
  Interesting point of view. The article is not really only about UML, but about formal specifications in general, and how Agile's rise affected them.
  • vegetablepotpie 6y ago
    Yes and UML is not dead, it was just never the tool that most people needed.
• msla 6y ago
  It's about as dead as flowcharts and Warnier/Orr diagrams are. https://en.wikipedia.org/wiki/Warnier/Orr_diagram https://en.wikipedia.org/wiki/Warnier/Orr_diagram
• throwaway4good 6y ago
  Yes. It was killed by post-it notes and coloured sharpies.
• jdlyga 6y ago
  UML's promise was that that with detailed enough diagrams, writing code would be trivial or even could be automatically generated (there are UML tools that can generate code). It was developed during a time when there was a push to make Software Engineering a licensed profession. UML was going to be the "blueprints" of code, and software architects would develop UML diagrams similar to how building architects create blueprints for houses. But as it turned out, that was a false premise. The real blueprints for software ended up being the code itself. And the legacy of UML lives on in simpler boxes and arrow diagrams.
  • ch_123 6y ago
    Completely agreed. As for why the code is the blue print - good code design requires the ability to switch between high level details (how do I structure these high-level components of the system) and super low level details (e.g. the application of a particular algorithm to a certain problem, or the various hacks and workarounds one often has to write when dealing with certain third party systems). The lower level details simply cannot be extrapolated from a high level structure.
    • lazide 6y ago
      To extend the construction analogy a bit - typical architectural drawings aren’t buildable as is. They often miss key details (member composition is rarely even mentioned, same with even member sizing!). Stamped civil engineering plans will often miss anything which is outside of the core structural elements being certified (so good luck figuring out the size of the beam you’re supposed to put somewhere if it isn’t a core load bearing element). Huge portions of construction are based off decades of (inconsistent) experience, in the field improvisation, cargo culting, and gut feel. The smaller/less big Corp the job, the more true this is.
  • agumonkey 6y ago
    The thing is I found quite paradoxical (to stay polite) that you'd spend time drafting something that is not precise, not data to help you but just a document in a tool. The model driven thing was nice but it was never good enough to actually help with code. It was also deeply rooted in the crippled Java days so full of verbose diagram representing overly verbose classes. To hyperbole a bit, I'd rather spend time writing property based tests and a few types in haskell in a way.
• haolez 6y ago
  There are some diagrams that I've more useful than others. My favorites: - Sequence Diagram: great for understanding distributed workflows - State Diagram: state machines are wonderful tools and having a standard for representing them is a win, IMHO - Parametric Diagram[0] (SysML): feels like Class Diagrams for functional programming [0] https://sysml.org/sysml-faq/what-is-parametric-diagram.html https://sysml.org/sysml-faq/what-is-parametric-diagram.html
  • thiht 6y ago
    Sequence diagrams are probably the most useful UML diagram. I don't know of a simpler way to specify and document workflows, no matter the scale (from function to whole system)
    • pautasso 6y ago
      https://www.bpmn-sketch-miner.ai/ https://www.bpmn-sketch-miner.ai/ Draw your workflow by writing down examples
    • contingencies 6y ago
      http://www.mcternan.me.uk/mscgen/ http://www.mcternan.me.uk/mscgen/ is awesome
  • DavidVoid 6y ago
    Now that I think about it, sequence and state diagrams are pretty much the only programming-related diagrams I see used in the documentation at my telecom job. I even see sequence diagrams written in code comments from time to time, they're always appreciated.
• Chazprime 6y ago
  It’s a great tool for those times I need to familiarize myself with a new codebase, but for my own projects it just becomes a pain to keep updated.
• AJRF 6y ago
  Other people in this thread have expressed it, but the reason it's not useful is because most developers are doing something like UML, but it's not UML - so you get none of the benefits of the Unified part. When I see a good UML diagram I know immediately what the bit of modelled code does. When I see a weird, cobbled together diagram of bits of code the creator thinks defines the state, I have gained nothing of value from viewing the diagram.
  • jameshart 6y ago
    In my experience, when I see a good UML diagram I know I am seeing a picture of how someone thought something was going to work before they (or more likely someone else) actually built it. It might or might not accurately reflect how the code actually works. In particular constraints the diagram claims exist may or may not actually be enforced in the code. The UML diagram says a Foo only exists for the lifetime of the Bar that references it; well, this memory dump from production says otherwise, so I don’t care what your diagram says, the code is what matters.
• musingsole 6y ago
  The trick is to tie your UML to your code with a few scripts. After a point, if you're manually interacting with it, you're doing it wrong. A lot like the AWS console.
  • lelanthran 6y ago
    > The trick is to tie your UML to your code with a few scripts. How do you do that?
• deleted 6y ago
  [deleted]
• zorked 6y ago
  Good riddance. UML is part of the infinite-complexity infinitely-layered culture around the Java language in the late 90's and early 00's. Where OO-supremacist "system architects" were trying to split software development into the first-class flying, conference-attending chosen few who could do modelling, and the unwashed masses who were to be replaceable, underpaid, be-glad-you-earn-more-than-minimum-wage outsourced code monkeys.
  • pjmlp 6y ago
    A culture born out of C++ and Smalltalk enterprise tooling before Java was even an idea.
    • acdha 6y ago
      Mentally I have this bundled in with 4GLs and the perennial visual programming environments, revolving around the idea that the act of coding was the expensive part rather than the application complexity. I understand the appeal of saying you can ship the diagram rather than writing code based on it but it’s always felt like the kind of thing which leads to a demo cliff where the simple parts are appealing but anything non-trivial becomes unmanageable.
      • CGamesPlay 6y ago
        > revolving around the idea that the act of coding was the expensive part rather than the application complexity. I just can’t wrap my head around this idea. If the act of coding isn’t the expensive part, then why should I have to spend so much effort coding and why can’t my effort be focused on the application complexity? I agree that UML and past visual programming environments weren’t doing a good job of splitting these concepts, but I don’t buy that this means it’s impossible to split this.
        • acdha 6y ago
          There’s definitely room to shift the work but I think it’s really easy to look at the amount of time spent writing code after the specification is “done” and say that it’s overhead without questioning how much of it was really due to errors, gaps, or misunderstandings in the spec (thinking memorably of a couple of projects “overruns” where the managers who thought the plan was done were wildly out of touch with their direct reports who’d been excluded from the planning process). I think a lot of business people also liked the idea of having one expensive architect giving diagrams to cheaper coders (probably in a different county), avoiding needing to give higher pay and social status than they needed to offer to be able to hire decent programmers. Something like UML is appealing if you want something you can look at to say it’s ready to hand over to be implemented and the numbers salespeople toss around for projected cost savings can make it appealing to pretend really hard that it’s that simple.
• danimal88 6y ago
  I never got the impression it had much life in it to begin with
• ch_123 6y ago
  My personal experience is that system-level architecture diagrams are useful (i.e. which service/application talks to which service/database/message queue etc.) but code/class level ones are not. As to why - because the code tends to change a lot more often compared with the overall architecture of a platform. Requirements change (or requirements become better understood), code is refactored once the engineers get a better feel for the structure they are solving, new tools come along, etc. Code level diagrams have a habit of going out of date quickly, or (even worse) discouraging people from making useful changes based on new information. To me, it seems that in their rush to criticize agile, the author failed to consider _why_ agile-like practices killed off UML.
• sitzkrieg 6y ago
  its still very alive in the MBSE world of SysML a superset, supported by many tools
  • Rochus 6y ago
    And at least as useful ;-) EDIT: here a few of my thoughts on the subject in case anyone is interested: https://www.quora.com/What-are-the-challenges-you-face-when-you-model-a-system-using-SysML/answer/Rochus-Keller https://www.quora.com/What-are-the-challenges-you-face-when-...
    • rjsw 6y ago
      STEP (ISO 10303) is moving to use SysML to define the models for the collection of standards. Part of the reason is to be able to use visual tools instead of defining everything using text.
      • Rochus 6y ago
        The versions of ISO 10303 I'm using are based on EXPRESS and EXPRESS-G; didn't see any SysML there; this even applies to ISO 10303-233, the systems engineering AP of STEP. There is a tendency towards RDF/OWL driven by the ISO 15926 series though.
        • rjsw 6y ago
          I wrote "is moving". Nothing has been published yet that has been developed using SysML, the first standard will be the next edition of one of ISO 10303-242 or 239 or the first edition of ISO 10303-243.
          • Rochus 6y ago
            References? Why should they do that?
            • rjsw 6y ago
• rubyist5eva 6y ago
  UML sucks because it takes forever and if your software changes you have to change your UML. I just use tooling that allows me to generate diagrams on the fly based on the existing code. In the planning phases I just use Draw.io, but that always ends up out of date and irrelevant once the system actually exist.
  • captaincaveman 6y ago
    I find this kind of comment ironic (your not the only one to make it), its this kind of thinking which lead to UML becoming a complex over detailed beast, rather than be a tool to consistently model intentions. If you model at the correct level of detail, you don't have pain keeping them in sync, one you start to model the implementation details you need to adding more complexity to your model to be able to sync the model :)
• waprin 6y ago
  UML is closely associated with Object Oriented programming. In the 2000s, OO programming was all the rage, and having a mental notebook of “design patterns” was considered the hallmark of a real software engineer. Since then, OO has lost a lot of its luster, the languages most associated with it like Java and C++ are considered somewhat clunky and uncool. Functional programming took over as the “smart” paradigm to talk about, even if in practice most popular programming languages borrow a mix of imperative, OO, and functional features. UML was also popular in a time when you could make a SQL database and just use that. The introduction of more database varieties complicates things. Besides OO, UML was also strongly associated with “visual” programming done by non programmers. This paradigm is doomed to be reinvented and pushed as the next big thing every 3 years until eternity, which we currently see with whatever the latest no code trend is, but in the 2000s was associated with UML. Finally, language independent data formats like JSON, Thrift, and protobufs got popular. Why make a UML diagram when I can just make the actual data structures then immediately have that as a binary format? To the extent UML means “data modeling”, people still do that. But it became associate with a lot of cultural baggage, and most of that baggage was on the losing end of a lot of technology mindshare battles.
• pjmlp 6y ago
  Like every kind of these questions, not at all and is pretty much alive in corporations. Here is one I tend to use with some regularity, https://devblogs.microsoft.com/aspnet/grpc-performance-improvements-in-net-5/ https://devblogs.microsoft.com/aspnet/grpc-performance-impro... And then there is Visual Studio Ultimate as well.
• xyst 6y ago
  speaking of uml, there was a general "software engineering" course at my uni and there was a section on UML diagraming. I remember creating these absolutely beast UML diagrams that looked more like spider webs. It was fun, but absolutely useless in the real world lol
• wirrbel 6y ago
  I think it highly depends on your work context, wouldn't exactly call it dead but firmly in the trough of disillusionment. Funnily enough, I think the author's analysis is a bit off, or rather misses essential points. They somewhat blame the procedural changes for a demise of UML. The problem they don't speak about that UML is not universal, it has serious flaws. # Complexity as a Modeling Language It can only be understood by those extensively trained in UML. Really, show someone a UML diagram and they won't understand them. What are those arrows supposed to mean? The boxes. etc. About a dozen different diagram types don't help either. In fact, I have seen so many faulty diagrams, activity diagrams that contain error and mistakes because the semantics were not properly understood that just confirms how complex UML is. Furthermore, I was in UML corporate trainings and the instructor made mistakes about UML activity diagram semantics, etc. It's that bad. From that perspective, thinking that a business person may be able to understand is wishful thinking # Object-Oriented Paradigm and the 'Encoding' Problem UML at its core assumes object-orientation. That means that class-diagrams replace Entity-Relationship diagrams. Class diagrams may work as an 'encoding' of ER diagrams, but its fairly complex. This is a pattern that repeats for a couple of applications of UML. It is possible to model a lot in UML, also by extending UML with its possibilities to extend it, but the results really look like a strange encoding and its hard to read these diagrams. Overall UML has replaced a Zoo of diagram types that were more or less established and the results are often not pretty. I made a deep dive once into diagrams of the 80ies and 70ies and overall a lot felt refreshing. # Model-based Engineering and Tool Vendor Takeover I haven't been involved in UML prior to version 2, but it overall feels like UML is a vehicle by vendors of UML tooling to sell their products and as such, UML has adapted the idea of model-based engineering. When the naive assumption of a software engineer about UML is, that a couple of Visio/draw.io/Dia diagrams will do, one learns over time that its hard to maintain these models, and the fix for it is to use a modelling tool such as Enterprise Architect or Rhapsody that contains a whole Tree of UML entities from which you derive your diagrams as viewpoints. Its like falling through a rabbit whole. If you manage to avoid this rabbit whole it just means you probably are only using a small subset of UML. I think this lead to UML becoming increasingly complex and the language standard should probably have been limited in a way that it remains useful without the tooling. # Lack of Block Diagrams and Data-Flow diagrams If you look at ad-hoc (non-UML) diagrams in open-source documentation and corporate ppt slide decks, or look at diagrams your colleagues draw on a whiteboard, what one really quite often sees is diagrams that show data flow, as in: "Frontend in the Browser requests data from the backend service, backend service retrieves data from the SQL database and the object-storage system". These simple relationships are remarkably hard to nicely communicate in UML. Hence, if you intuitively start to describe a Software system, UML will not make it easy. # Whats the alternative? I am personally a huge fan of FMC (http://fmc-modeling.org http://fmc-modeling.org) but am the first to admit that it is a little obscure, but it offers everything I consistently need. * block diagrams for data-flow and system interactions, structure * Petri nets for behaviour * E/R diagrams for data structures. Surprisingly, the diagrams seem to be fairly approachable for engineers and business people alike. A lot of the micro design decisions for the FMC diagrams have been done right. In block diagrams, arrows point in the direction of data flow, everyone can understand that. In E/R diagrams, the 1:N relations also have arrows pointing to the `1`, that's somewhat easy to grasp. Petri nets are equivalent to UML's activity diagrams, but don't omit the drawing of 'places'. With places being drawn, people have at least the chance to grasp the semantics and firing rules (that are also present in UML's activity diagrams but people just don't make that connection).
• njacobs5074 6y ago
  UML has been on life support for a long time because it served no real purpose for either engineers nor business users. Any UML diagram that accurately captured complex business requirements was no easier to understand than the pages of code, databases deployed, and a gazillion other things that are required to run any modern corporate.
• muterad_murilax 6y ago
  So, is that RIP or RUP?
• ridaj 6y ago
  My personal view: kill the garbage that is UML with fire, and all the attempts at formal modeling. Design is too rich of a field to be modeled formally. I disagree with the author's apparent take that all there is is either formal UML-type thought systems or a mess of design-less fluffy user stories. There is room for both. But a thoughtful design represents and communicates deep thought, and formal design systems like UML, in my experience, do not help people communicate deep thoughts. The best design documents that I've read were very well-written prose, with occasional diagrams for illustration, or even code snippets, but not trying to convey too much in a formal manner which would've made the doc less readable not more.
• 1ris 6y ago
  I think uml is not a efficent way for me to pick up information. I learn them in the university and all, but don't think i actually used them really on my jobs. When I look up a design pattern, I try to understand it from a uml diagram, but almost immediately quickly jump to wikipedia for example code, as i consider it way more digestible. Not a coincidence, since i deal with code every code, with uml diagrams almost never. For states, I like plain old state diagrams. Same goes for creating design: I prefer sketching code in notepad in a some kind of java/c++/python frankenstein over drawing uml. I only find the the Doxygen generated inheritance hierarchies to be usefull.
  • segmondy 6y ago
    sequence diagram is a great way to understand events between components/systems more so than diving into the code base.
• disposekinetics 6y ago
  I've never seen UML used at a company in any form, despite being required to take a class that taught UML.
• nraynaud 6y ago
  no, I got a recruiter contacting me for some UML thing recently. Well, it was the Paris metro company, so I guess UML is dead, and they just got their "UML project" together.
• jameshart 6y ago
  I don’t get the example given here that shows three steps joined by arrows and claims that the diagram is ambiguous about the order of execution of the steps. The steps are called step 1, step 2 and step 3. The arrows between them must imply some. Kind of sequencing or dependency. If the person who drew the diagram didn’t mean to communicate that the execution sequence was step 1, then 2, then 3, they should have given the steps different names. Simple dependency or data flow graphs like that are great for recognizing redundant dependencies, for example - like noticing ‘step 3 uses the results of step 1 and step 2, but step 2 depends on step 1 so we can just simplify this down to a sequential process - or we need to break the dependency of step 2 on step 1 so we can parallelize them’ This is notation to help you use pattern recognition and visualize structure to make better decisions, not to capture the final design. Diagrams are for helping with the ‘working out’ phase, not expressing the solution.
• bryik 6y ago
  The UML specification is 796 pages[0]. It is amazing how humanity can take simple concepts like flow charts and inflate them into insane, hyper detailed legalistic rule books that almost no one understands or uses. 0 - https://www.omg.org/spec/UML/2.5.1/PDF https://www.omg.org/spec/UML/2.5.1/PDF
  • hu3 6y ago
    If you complicate things enough you can sell consultancy and certifications.
    • r3dapple 6y ago
      This also applies to modern IT security
      • marto1 6y ago
        and as we all know - really complicated security models are the very bedrock of a sound and secure system. /sarcasm
    • anthk 6y ago
      Red Hat/IBM.
      • rootusrootus 6y ago
        Atlassian.
      • fogetti 6y ago
        Google/Amazon
  • rjsw 6y ago
    You could also add in the page count for the specifications of SysML, DD, MOF, OCL, QVT and XMI.
    • 6y ago
• seanmcdirmid 6y ago
  There were a bunch of academics in a certain rich EU country that dumped a lot of research dollars into UML (via their own research and their control of funding agencies and committees). That they’ve mostly retired by now probably has a lot to do with rapidly declining interest in UML.
  • josalhor 6y ago
    My teacher in Software Engineering that "taught us" that UML is used everywhere in CS and business. Looking up their CV, they only had two years of experience outside academia, and that was 20 years ago.
• epx 6y ago
  UML acronym means “programmers are just typist monkeys and should be paid peanuts”.
• spaetzleesser 6y ago
  In my view one of the biggest problems of UML was that it's ugly and not very intuitive. For a while I jumped on the UML bandwagon and developed a lot of diagrams of the various types. Turned out that even very experienced developers didn't understand them not even to mention less technical people. Now I just draw a few boxes with arrows and usually get the message across. UML as code generator also made for really neat demos but in practice the diagrams for complex systems were harder to read than the code. If I had one wish it would be nice if there was a standard for embedding and editing diagrams in different software like Word or Powerpoint or the web. It seems you always end up copying/pasting stuff while often losing the original after a while.
  • adriancr 6y ago
    check out plantUML - nice text commands to create models, useful enough for the 'few boxes with arrows' use case that I also run into often.
    • spaetzleesser 6y ago
      It would be nice if Word had an interpreter for this. You enter the model text and Word renders it. Same for graphviz. My life wild be much simpler if Word rendered them.
• dragonwriter 6y ago
  Three things happened to UML: 1. Diagram-driven code didn't pan out as well as advocates hoped (and to the extent it was useful, UML wasn’t a great language for it; BPMN was less bad at this.) 2. Modeling and analysis became devalued, adversely impacting modeling languages 3. OMG also ended up as the owner of BPMN (which was also affected by the first two factors) which has enormous overlap in function with UML. So, with a reduced role for visual modeling languages you've got two competing standards in the area from the same organization, neither one of which is really adapted to current usage patterns.
  • robertlagrant 6y ago
    It's not been my observation that the overlap is that big, having done lots of BPM work using BPMN in a former life. BPMN is for describing much higher level processes than what UML is for.
    • nickkell 6y ago
      How did you like it? We're using it via an executable process engine at my current company on a project that's not yet in production, so I'm still on the fence. I have no idea if anyone from the "business" side will ever look at these diagrams, and if it's just the developers looking at them, then why not look directly at the code with the support of a modern IDE?
      • robertlagrant 6y ago
        It works well for business processes, e.g. here's one I did: capture credit application; do auto check for credit worthiness; do rules check for amount requested vs credit worthiness to trigger auto approve, auto reject or manual approval gate; submit save approved loan details to mainframe for money issuance. The tools I used generated a system using storage-backed messaging between every step for reliability, and then I could plug in a UI or an integration where needed, and generating monitoring screens to illustrate where in the process things are, cycle times, etc etc. If you use it like that, as a config language you can use to drive creation of other things, it can work well, and it's a pretty mature standard, so it can describe lots of possibilities.
• adriancr 6y ago
  I still see it used and use it myself. You sketch out simple diagrams of major modules and how they interact. That gives an understanding of what goes where and how things interact at high level. You dont detail each function/attribute/call/... you'd go insane and it would be useless / you'd lose your readers time. (If they want this level of detail they can check the code) It's also useful when doing new big features where you need approval/feedback/advice. One simple class like diagram to show how you structured your code is generally useful for people you present it to to understand what you want. Some use cases like sequence diagrams are also useful. Then you detail out further in whatever is agreed in the company. Sometimes its useful to describe flows for really complicated bugs with a sketch like sequence diagrams to make sure you undetstand and found actual root cause and to show that.
• Anon84 6y ago
  Was it ever alive, really?
• thomasfl 6y ago
  Sequence diagrams is actually good. The initial idea was improved before it became a part of UML. https://en.wikipedia.org/wiki/Sequence_diagram https://en.wikipedia.org/wiki/Sequence_diagram
  • pvarangot 6y ago
    Yeah came here to say that. I use sequence diagrams a lot to illustrate complex processes before starting to implement components and stuff like that. But they were "co-opted" by UML, the idea is older than the whole mega-effort to make UML a thing and automate software engineering.
• 29athrowaway 6y ago
  I do not think UML has died. Is it not uncommon these days to see UML sequence diagrams, for example... I would describe the situation as: - UML offers a lot of stuff, but only some of that became widely adopted. - When stuff gets really ugly and complicated, UML can help by providing a high level view of what's going on in ways that are really hard to achieve just from memory. Sometimes I use PlantUML to create diagrams to keep track of things. PlantUML is a format that is source control friendly, so I can check it in my docs folder.
• tarkin2 6y ago
  UML died alongside the waterfall method. UML, especially defining the method names et al, before you coded anything was an extreme of the waterfall method. I think generating UML from code could have been useful. But I was much more likely to grasp more of the system from a paragraph or two or well-written text. Well-written UML rarely helped. Roughly sketched boxes with arrows and a bit of text are the most useful.
• JoshCole 6y ago
  A lot of others have talked about the UML aspect of this post, but I want to speak to something that was more in the latent space of my reading of the post and its dislike for agile trends and a kind of supposition of something being lost by losing UML. It seems to me that people emphasize the success of engineering disciplines outside of software engineering as a way to show the weakness of software engineering, but I think this way of looking at software engineering artifacts is misleading. Optimization algorithms have some pretty dismal outcomes when you choose to analyze at a particular point in time, especially when you choose a failing artifact, because those failures are absolutely intentional and critical to the proper functioning of many types of optimization processes. As an example generative discriminating processes, like GANs and like Software Creation + Chaos Engineering as popularized by Netflix, thrive on the creation of failure. Yet if you focus on the examples of failure you're missing the forest for the tree whose death is fertilizing the soil of the forest and resulting in a thriving ecosystem. Yes there was failure, but that failure wasn't an indication that the practice itself wasn't holistically valid. The failures were the means by which success was obtained. This falls directly out of the mathematics of learning. The field envy of other engineering disciplines is misplaced. The limit of these optimization processes when expressed in code tends to be machine learning. These optimization processes result in learned creations of superior quality to what is currently produced and it seems highly likely that most fields that don't embrace this will find themselves out-competed by disruptive upstarts who aren't blind to the benefit of new technologies and workflows. Likely, some of these upstarts will be startup founders who frequent this site. When you look at a time slice, failures look terrible. When you look at a longer period of time: failure is smarter than success. Risk aversion is self-destruction; die to live or you'll live to die.
• codeulike 6y ago
  I like the concept of 'Masala diagrams' that OP introduces - I've drawn these a lot, and the UML-trained part of me is always slightly uneasy that I'm combining (say) data and process flow on the same diagram, or that some of my boxes are physical machines and some are programs, etc. But the thing is, you shape your masala diagram to communicate whatever the thing is you want to communicate. You'd need 3 or 4 UML diagrams to cover the same thing, and no-one would really care that you'd bothered to keep to the conventions.
  • bccdee 6y ago
    IMO diagrams work best in tandem with actual docs. The diagram is an abstract — you glance at it to get a high-level understanding, and if you need to deal with the details you can look at the writing. UML always gives me a headache; I hate having to squint at a diagram to deduce details that I could just be reading about.
    • illuz 6y ago
      What's IMO diagram?
      • bccdee 6y ago
        IMO = In My Opinion
    • deleted 6y ago
      [deleted]
    • codeulike 6y ago
      IMO diagrams work best in tandem with actual docs. "IMO diagrams" are my favourite type of diagram
• birdyrooster 6y ago
  Nope, I still use it, and many others too, for sharing design ideas.
• mkl95 6y ago
  These days UML is the kind of thing I mostly expect to find in xkcd strips. I have been writing software for a few years and I haven't seen anyone use it non ironically outside of academia.
• edgarvaldes 6y ago
  Whats the better alternative, if any?
• dexwiz 6y ago
  UML are blueprints, but blueprints are not the thing, just like maps are not the land. Talk to anyone in construction and their first complaint is often the blueprints are wrong. They may have missing or extra space, call for impossible things, changed since the project began, or be flat out wrong. Whether the blueprints are actually wrong or we’re not followed is up for debate. So if UML is blueprints, it’s not that they failed. It’s that the creators misunderstood the actual fidelity of blueprints. They will never be perfect enough to replace implementation. Sometimes I wish for more formal planning, and that real design could be done before code. But instead of building a design process, programmers immediately saw a way to automatically generate code, and in that they made UML useless.
• mattlondon 6y ago
  I don't know about the rest of it, but sequence diagrams are alive and well and are basically in pretty much every design doc I write and read. They are very very useful for letting people quickly gain a shared understanding for what a system is supposed to do (at a high level). They are extremely beneficial IME. If you are designing a system and need other people to understand key parts of how it all hangs together (e.g. during review or implementation or maintenance) , and you are not using sequence diagrams, I'd urge you to strongly consider doing so.
• rytis 6y ago
  There's quite a lot of hate in the comments for UML is seems. And while a lot of it is quite valid, I have to say that sometimes I miss _some_ of what UML could do, especially in form of documentation. Sometimes a simple sequence diagram is able to communicate the behavior of a system much clearer than 10's of pages of disjointed prose... Just my opinion.
  • jugg1es 6y ago
    Nothing is stopping you from creating diagrams, but UML is not required to create useful diagrams. Most concepts can be diagrammed using only boxes and lines.
    • jhayward 6y ago
      This could only be said by someone who hasn't sat through their Nth architectural overview where half the time is spent defining just exactly what was and was not intended by a particular line+arrow between two boxes when a simple sequence diagram would have been crystal clear.
      • jugg1es 6y ago
        Both simple box+line diagrams and sequence diagrams are entirely dependent on the creator's skill at creating diagrams. I've seen plenty of confusing sequence diagrams. I guess it also depends on whether your team find it useful that diagrams depict low-level highly detailed interactions as opposed to higher level architectural concepts.
  • jorl17 6y ago
    Sequence diagrams are the one UML diagram I regularly still produce to communicate behavior both to other developers and less technically minded people. I personally find them great (as long as you don’t get carried away in very minute notation)
• ok123456 6y ago
  There's a impedance mismatch between UML and actual programming languages. Idiomatic python is different from idiomatic java, and trying to make UML as it was originally intended, to be a detailed, formal specification of a program, is quite at odds with that. You either end-up having to ignore most 90% of the diagram, only using the high-level details, or you end up with programmatically generated garbage code.
• indymike 6y ago
  The problem with UML is that it could only represent certain functionality... and counted on code generation / translation to make it happen. It was an extra step. It was much more useful for analyzing and diagraming code, but that too was limited by whatever analysis was being done to generate UML.
• danellis 6y ago
  I don't remember all of UML anymore, but I still use sequence diagrams, activity diagrams and state diagrams. Using something standard is just easier than having to think about how to represent something, and then explain your representation to someone else. During the design phase, I'll usually write PlantUML code in IntelliJ and have the real-time preview fullscreen on another monitor. It's a nice setup.
• emodendroket 6y ago
  I've been at it 8 years and never actually seen anyone use it, so I think of it as a relic of an era before my time. I don't really agree with the premise that this is a big tragedy though. There's a danger of getting carried away with the analogy to traditional engineering but the cost of changing things in software is much lower, so exploratory work is much more viable.
• boyadjian 6y ago
  There was a big UML fashion in the company where I work, they even hired a specialist in the subject, did training. And a few years later the specialist left, and no one made UML anymore
• neilv 6y ago
  I used to develop next-gen high-end OO CASE tools, and am big into systems analysis/design/etc., visual thinking and communication, etc. A few random comments, on latest impressions of UML, while trying to get something done last week, but not a rigorous look UML... I happened to skim parts of the UML spec (796-page PDF) last Thursday/Friday, having not seen UML in a while. I appreciate all the goodness from various methodologists that was incorporated into UML. And, especially as a tools developer, I also appreciate the semi-formal metamodels, which have a few key uses, most of them for tools developers. Unfortunately, the particular UML features I needed last Thu/Fri (for a cross-org high-level process&architecture model) didn't seem to be supported sufficiently well (or at all) by any of the first half-dozen UML tools I tried. (I tried open source, and then lightweight Web SaaS. People generally do that, maybe more SaaS first, and want to get started rapidly. I'm not going to casually install a huge closed CASE platform, without checking the SaaSes and open source.) By Friday afternoon, finding all these tools hindered more than they helped, I said "fiddlesticks this barrier situation", and decided to just use our GSuite Draw. Although, on the surface, it appears to be pretty much 1980s shared-whiteboard simple drawing CSCW (with a little 1990 Visio diagramming innovations), I was able to express enough of what I needed without too much effort, and I was even able to reason from the diagram a little as I was manipulating it. To make GSuite Draw viable for my immediate purpose of starting to work through a model, I did have to use a metamodel and notation that was easier to draw without special tool support, but it worked for this particular model. I'd still use a specialized UML tool for the most familiar Rumbaugh-ian static object modeling. And, if the tool supported them well, I'd also use for Harel state modeling, maybe event traces, maybe Jacobson use case modeling, and some other UML ones (e.g., Activity Diagrams, especially with the object flows, not just flowchart control flows). I wouldn't generalize much last week's experience, to adoption by developers in general, since I'm a fringe person who knows specific metamodel features that exist, which I want to select for a particular need -- rather than being a new person dropped in front of a particular kind of UML diagram, and told to start expressing my system in whatever terms it gives me. I haven't done a rigorous survey of current method&tool practice and offerings, but I'm starting to form a suspicion that adoption and execution challenges for UML-ish things today are very similar to what they were 20 years ago. The markets certainly seem to have changed in some ways, but even some of those ways (e.g., more widespread framework reuse), were already being talked about for modeling 20 years ago.
• marto1 6y ago
  I mean, I hope so. Never really met anyone overly excited about it or any of it's applications. Plenty of people on the "hate it" side, though.
• deanclatworthy 6y ago
  I think all of us who studied CS (at least over 10 years ago, no idea what's being taught now) hated UML. That said, there have been plenty of times where I have used certain kinds of UML. For example, sequence diagrams [1] are a great way of modelling certain processes between actors and objects within your system. I even used once a few months ago to help a client understand a complicated part of the system we had developed. I tend to think more junior CS graduates might end up pulling this kind of thing together using sticky notes in some web 2.0 board. [1] https://plantuml.com/sequence-diagram https://plantuml.com/sequence-diagram
• perfect_kiss 6y ago
  I don't agree with the posting. In my opinion, UML had rebirth in 2010s with the growth of popularity of PlantUML. See that PlantUML is referenced already in this thread, and to positive sentiments already expressed, I can add the notion that PlantUML fits much better, than most of earlier UML related software, for the purpose of network modelling. While original UML standard was not specifically designed for representing networks, PlantUML has network diagram type built-in. And extensibility of PlantUML allows to cover many use-cases beyond that. I imagine that with a certain amount of tenacity applied, it would be possible to create PlantUML library for "masala diagrams" as well. Also, "agile" shops usually love that tool, since it requires minimal learning curve for any person on a team to start producing nice-looking diagrams.
• aidanr 6y ago
  UML as a way of detailing the low level implementation of a system was, IMHO, a really bad idea. I say that as someone who once drew up all the GoF patterns in UML in Borland Together and then tweaked the generated Java code to do have running Java code for what the patterns said. But there is a world of difference between "UML as a sketch" and using a diagram to constrain what actual code your co-workers actually write. Sure – Fowlers’ UML Distilled is still handily placed on my bookshelf but even from when I first read it, I knew that I was never going to draw class diagrams from three perspectives (conceptual, specification ad implementation – leaving aside the GoF practice above). And in the 20+ years experience since UML became a standard I don’t think I ever did. But turning it around, what diagrams do you draw when - You are in front of a whiteboard and are trying to communicate with half a dozen (maybe microservce based) teams that you need X to happen before Y but the daft business require you to pass a new bit of data through 3 of the systems to implement this. - You are in front of whiteboard with some of the newer members of your development team trying to work through what parts of their development can run in parallel and what parts must be serial (because the product owner is new and can’t get to that level of detail in words or drawings) - You want to explain to the business that one of "these" will own many of "those" unless (and if you are getting ambitious in your whiteboarding) the guard condition is that it is a pink moon or its aries ascendant Me – I want one "diagramming language" to realise my witterings in. And that one "language" was always sketched UML for the last 20 years. Sure – if I was a database designer implementing a problem with a relational database I might well use a ER diagram. But that is simply acknowledging diagrams are so much better than words for sharing ideas and the diagrams should be appropriate to the level of abstraction being dealt with. As a previously enthusiastic Scala user, I'd say that the role for UML has been _very slightly_ decreased by the shift to functional from OO. But not much. The functional example of "map X to Y except when ..." is really about implementation detail and I think most people are happy not diagramming at that level now.
• disordinary 6y ago
  The reason we stopped with UML and other front heavy planning methodologies is that what we planned was always wrong. Software projects always used to go massively over budget, were delivered late, and usually didn't meet the customers requirements anyway. It turns out that customers don't know what they want, or at least can't articulate it properly to business analysts. By delivering early and often, we're not only releasing value to our customers early and often but we're getting feedback, allowing us and the customers to go on a journey of understanding their needs. Also, it turns out that engineering teams know better how to develop a piece of software than architects. We solve the complexity problems by breaking a project down into (as he says) "pizza team" size components and focus on defining the interfaces between those components, rather than go into the weeds of how information flows within the code. This leads to other complexities, of course, but they don't lead to the same sort of delivery problems that large, monolithic designs have. All in all, a switch away from a design heavy approach has improved delivery, value to our customers, and enabled staff to be more productive.
  • suzzer99 6y ago
    Exactly this. You never know your problem domain as well as you think you do. I always try to start a new project assuming everything could change. Paradoxically, this approach tends to produce the same net result as assuming nothing will change. If you have no idea how requirements will evolve over time, there's no point guessing. Just write the code needed for the first batch of requirements, and nothing else. It is orders of magnitude easier to add a layer of abstraction to a simple system when new requirements demand it vs. remove a layer of abstraction later when you finally realize you don't need it. The latter is often impossible.
    • nightowl_games 6y ago
      Hundred percent. I mentally call this "dumping all the Legos on the floor". I think of abstracting as "sorting Legos" and think of the process of writing the minimal code as "dumping the Legos on the floor". Once they are all on the floor, is easier to sort.
    • andi999 6y ago
• makach 6y ago
  I replaced UML with Archimate, I hated where UML was heading and the concept of dropping code/reverse engineering from source code - the idea was novel enough but definitively snake oil. Architecture is important, this is nicely achieved with Archimate imo. What works for me might not work for you. I still use some elements from UML but usually on a whiteboard as either use-cases, simple sequence charts or state diagrams. The code is self documenting.
• nitwit005 6y ago
  Past a certain scale it just seems easier to read text than visual diagrams, and since apps have tended to get more complex over time, we're reaching that scale more often. I've worked at two companies that started with database schema diagrams, but gave up on it. They got too complex to be useful, and people stopped looking at them.
• mark_l_watson 6y ago
  I do-wrote a UML for Java book with Paul Harmon, many, many years ago. Now, the only UML that I use are Sequence Diagrams - a favorite notation for expressing time based things.
• FpUser 6y ago
  Rational was set to conquer the world. Never good idea. However I still use some of their ideas and StarUML diagramming tool to help document preliminary design, use cases, deployment etc. It makes communicating to non tech persons way simpler.
• jillesvangurp 6y ago
  Agile killed off UML. Pre-agile, people were either doing really slow iterations (spiral development, rational unified, etc.) or just trying to do waterfall because that what people learned in school. Either way that meant obsessing over requirements for a while and then doing an actual design phase before you actually did any coding. And of course that required lots of diagrams and documentation; if only to give management some sense of progress (which to be fair was often the main point). UML merely tried to standardize that practice. And then IBM bought Rational around the same time the Agile Manifesto was signed. IBM buying Rational emphasized how corporate things had gotten and drove the point home that the Agile Manifesto signees were trying to make that basically was about eliminating inefficiencies and bad decision making from software development. Extreme programming introduced the notion of a sprint measured in weeks and the notion of having working code at the end of each sprint. Later scrum, kanban and other agile methodologies copied at least those parts of the process. Whichever your flavor of Agile is, two weeks does not leave a lot of room for maintaining artifacts that don't evolve along with code. Like UML diagrams. You draw a nice diagram, then you code for a week or so, and then your diagram is out of date. You could fix it by dedicating time to that. But you'd need to do so every two weeks. Or you just skip the part where you obsess about having diagrams and just move on straight to just worry about how to best run sprints. Extreme Programming was extreme because it intentionally skipped both requirements specifications and design documents as things because they realized that requirements were a combination of wrong and out of date because of things you learned during the project. And consequently, the designs were wrong as well. You do a little bit of requirements and design each sprint. That's called a planning and estimation meeting. Requirements are called user stories now. And since there is only so much you can do to a software system in two weeks, you don't need a lot of UML documents to describe the changes you are going to make. Along with Extreme Programming came tools like white boards, camera phones, and wikis. You use them to do a little white board session with typically some simple diagrams, you snap a photo of the whiteboard, and then put it on a wiki where no-one ever looks at it again. Good enough if you are doing two week sprints. The second you wipe the board, it fulfilled its purpose: sharing and communicating ideas and getting some consensus. So, that's why UML died. It's no longer needed. Too expensive to create, more expensive to update, limited value once you have it, very limited shelf life once you stop maintaining it.
• pachico 6y ago
  What did I miss? I use it every day and it works perfectly!
• major505 6y ago
  This is what happens when writing documentation owuld take the same or more time than writing code. We all see that most "no-coding" auto generating approaches to software development did not work except for simple solutions, and the irony was that the people who had time and manpower for uml where the one with most complex need of software.
• neovive 6y ago
  I tried UML years ago with little success. I recently started working with BPMN 2 with some success -- swimlanes are easy to explain and make sense to most people. ERD's are still my favorite notation and really stood the test of time!
• adsharma 6y ago
  Replace UML with python data classes. You'll be much happier
• ssn 6y ago
  No, unfortunately is a sign that documentation is not being take seriously.
• sgt101 6y ago
  The problem I found was that no matter how careful we were in drawing the UML there was always one box on the diagram that turned out to be the "pandora box". When someone started work on it it suddenly became apparent that all the complexity of the system lurked within - and we could never be sure which one it was or how to get rid of it/them.
• hackbinary 6y ago
  And now we have MS Flow. And other "codeless" programming tools.
• mszcz 6y ago
  In my college years I've been told a lot of things by my profs. ORMs will kill RDBs, UML is the shit, Agile is the future of all software engineering etc. I could never see most of those things happening but always assumed that they're smarter so they must know what they're talking about. It's kind of satisfying but also profoundly sad that they were both wrong and failed to instill a reflex of questioning authority in their students.
• Marazan 6y ago
  UML's problem is that it is boxes-and-lines. The trouble with boxes-and-lines is that they work fine for small problems and collapse in a mess of overlapping nonsense for complex situations. This is not a UML specificthing. Any visualisation that is boxes and lines that is not a strict acyclic single parent heirachy is doomed to failure for anything complex.
• atum47 6y ago
  I started college back in 2016. I saw uml from day one. Never actually used it outside college. We used a lot of those tools that can generate diagrams from code and vice versa, but I personally never liked it.
• darepublic 6y ago
  Rational rose anyone
• unixhero 6y ago
  UML failed because it kind of sucks, right? I like drawing dataflow when mapping integrations in IT projects out with UML flow diagrams, such as this[0]. But other than that I have never seen anyone use them. I could never find a use. [0] https://www.researchgate.net/figure/UML-data-flow-diagram-between-the-different-parties-Note-big-arrows-mean-broadcast_fig14_318700916 https://www.researchgate.net/figure/UML-data-flow-diagram-be...
• jiriknesl 6y ago
  I think, the biggest issue with UML is that it helps with things that doesn't need such a ceremony and doesn't help in things where you would need it. Modeling database structures, class diagrams, interactions between components is usually something, any senior developer can do on a napkin without all the hassle, certifications, $500+ per seat tools and unique terminology. The trickiest things are designed much better, when you just open REPL and start playing with the design until you get it down. It's highly creative, speculative and flexible. So exactly the opposite of UML. In programming, the most exciting parts are things you couldn't productively solve with UML. And calling diagrams Masala is a huge misunderstanding why people mix contexts, views and representations. This is that creative, speculative and flexible part you exactly need.
• quux 6y ago
  I think the only UML diagram with real merit is sequence diagrams. I use those all the time.
• plank_time 6y ago
  UML is the same line of thinking as J2EE which is the worst thing I’ve come across in my 25+ year career. J2EE took software complexity and made it not only more complex but catastrophically tedious. And then the “experts” were no longer software developers but bureaucrats. It was the perfect way to destroy Java and enterprise software. UML was along the same lines as J2EE that rewarded bureaucracy and tedium. UML is a relic of the worst parts of enterprise software back in the mid-naughts and I’m glad it’s completely dead.
• mmcnl 6y ago
  > In a model in which you pour user stories into a sausage machine, and you get a demo at the end of it (or a feature production release in a DevOps shop!) there is no room for purposeful, structured problem analysis anymore. This couldn't be further from the truth.
• nine_k 6y ago
  UML has a few good parts: sequence diagrams or use case diagrams, for instance. These few good parts can be used, or lifted from UML, without the rest of the UML baggage.
• cartoonfoxes 6y ago
  I've never encountered UML in the wild, but could say a few good words for SysML, which is built on top of UML. Working on embedded software / hardware projects I've found SysML to be quite useful for systems design and documentation. Mostly BDD, IBD, Sequence, and State Machine diagrams. Parametric diagrams will probably come in handy at some point, as well. SysML users tend to be in less vocal industries, especially those making expensive expensive hardware with lots of up-front design eg. defense, aero, medical, etc. I expect we'll keep using it until something better comes along.
• fatbird 6y ago
  Ironically, UML diagrams are still very useful for their immediate purpose, whatever that is. I frequently use timing diagrams just for my own sake because having to articulate something always adds clarity, showing you where you were handwaving something in your head. It's the draw.io version of rubber ducky debugging.
• sli 6y ago
  My entire experience with UML was as a high school aged kid who'd just found out about it, but despite my best internet searching, could find absolutely no resources on learning or using it. So I just gave it up and this post is pretty much the first I've heard about it since c. 2002. So... yeah, sounds like it. Everyone I know that needs something UML could do just uses Draw.io these days.
• galaxyLogic 6y ago
  UML started from the premise that software is a model of the world. But in fact what software really is, is a model of a low level program in assembler or binary we want to construct. But the proponents of UML didn't realize that either you must model the real world or you must model software. They are not the same. "Modeling software" really means writing a program in a high-level programming language. The failure of UML was it's schizophrenia: Was it made for modeling the world, or for modeling programs? If it had realized that is the case its creators would have asked: "How can we create a more high-level programming language than already existing ones? But UML creators were happy to claim that they have a great "modeling language" because then there was no real need to make it executable. The fact that some applications could produce some Java-code from a UML diagram does not mean they could create full running programs from it.
• lerno 6y ago
  UML died because while people were buying UML to live the dream that programming could now be reduced to charting classes, real programming doesn’t work like that. All it added was some meaningless documentation that looked impressive but got out of date approximately immediately after the first class was implemented. For a while people would still pretend to use UML (even though they actually didn’t), but eventually we didn’t even bother pretending.
• WalterBright 6y ago
  Back in the 70's, some contracts required that a flowchart for the code be delivered along with the code. The idea was programmers would prepare a flow chart as a specification, then implement the code according to the flow chart. What actually happened was programmers developed the code in Fortran, then ran a program that read the Fortran code and produced a flow chart on the printer. After a while with this, the flow chart requirements were abandoned.
• wait_a_minute 6y ago
  Hopefully
• ThomPete 6y ago
  Whenever my venture studio briefs developers with a new product that needs to be developer we do so in what we call a high definition UML. Which contains all the logic but centered around fairly high definition ui wireframes, sometimes even design. It's the best method we have found so far to brief developers and for them to follow.
• whatgoodisaroad 6y ago
  I've always thought of OOP as structuring a program the same way you'd structure a business. There are distinct divisions with responsibilities and internal state, with somewhat well defined ways to communicate with each other. Part of why OOP got so popular in software businesses is because it removes an impedance mismatch between the functions of business and the software it produces. In this view, UML is a kind of intermediate bytecode between business planning and software planning. Where it falls apart, IMO, is that UML is too granular for business functions, and it enforces a probably suboptimal OOP way of approaching technical problems.
• mybrid 6y ago
  Fortune magazine predicted this back in 1992. They did a study that correlated the growth of developers graduating from college was either flat or linear. The growth of computing needs was exponential. The end result of would be an exponential decrease in discipline in software as amateurs, hackers, trades people and what not necessarily fill the void. There is no other outcome. The challenge is for those areas such as military arsenals, power grids, healthcare and other safety domains to firewall off from the undisciplined masses and enforce discipline. However, Fortune pointed out that capitalism doesn't reward safety when its cheaper to hire good lawyers and litigate. So Fortune also predicted an explosion in tort and tort lawyers. Verner Vinge wrote about this in his novels. He supposed that rationalization will ensue and that undisciplined code will be seen as security through obscurity, a Gordian knot of convolution. One possible scenario is more-or-less Skynet were a few computing centers replace millions of devices. This makes sense from a capitalism perspective and governments can a few tightly controlled central services. So those are the choices given human nature. What's not a choice is an increase in discipline because, you know, human nature.
• indus 6y ago
  This fall was impending. The software components were invented faster than their representation of business components. I remember facing this dilemma early on in 2000s. When I was writing JSP (Java Server Pages), we did not have an easy way to ‘model’ a JSP as a software entity in UML. A JSP did serverside logic as well as Frontend. Then a forum suggested that we do what happens underneath that a JSP is compiled as a Servlet and model them as ‘JSP_Front’ and ‘JSP_Back’ as the accurate representation. Architect
• contingencies 6y ago
  UML - Unnecessary Management Lingo. - @iamdevloper UML - I know next to nothing about UML - but what I do know is the language was invented first and then people came around and tried to give semantics to the language. Well, in other words what that means is that the language was invented first and it really didn't mean anything. And then, later on, people came around to try to figure out what it meant. Well, that's not the way to design a specification language. The importance of a specification language is to specify something precisely, and therefore what you write - the specification you write - has to have a precise, rigorous meaning. - Leslie Lamport UML: a language that was invented first and then people came around to try to get semantics. - Leslie Lamport UML: fuzzy pictures of boxes and arrows. - Leslie Lamport People use UML, things like UML, to model programs, but it's not clear how to translate them in to sequences of states, for concurrency. If you cannot translate them in to sequences of states, it means you don't understand them, and it may mean that there's nothing there. You know, there are lots of people selling snake-oil, drawing boxes and arrows that make you feel good, but ultimately have no real meaning. If something is really meaningful you should be able to express it in mathematics. - Leslie Lamport ... via https://github.com/globalcitizen/taoup https://github.com/globalcitizen/taoup
• u678u 6y ago
  Rational Rose was the most expensive, worst piece of software I've ever had to use. It made me completely lose faith in formal design methods as a process, both because the tool sucked, but if the gurus of professional engineering did their best and produced junk, you lose faith.
• quantum_state 6y ago
  The software engineering industry has simply decayed into chaos ... it’s mostly blind leading blinds ... abstract thinking and design have been replaced by Radom walks ....
• deleted 6y ago
  [deleted]
• kumarvvr 6y ago
  If something dies without anyone noticing, it has no value whatsoever. Good riddance. As a new software developer in IBM, UML scared the hell out of me. It gave an aura of needless complexity to software problems that needed to be tackled by breaking them down into manageable chunks and apply time tested solution patterns. And the whole Architect thing in IBM, oh my god. They were literally seen as demi-gods that everyone aspired to be. Really bad entry into software engineering for me. (I have come out of IBM, so all is well)
• jcims 6y ago
  Was UML ever alive? I’d never seen it adopted beyond curiosity anywhere.
• sirsuki 6y ago
  I use UML now just to make sense of the huge complexity in code (front end dev) activity charts for logic, sequence charts for debugging, state distances for UI states. I have found it invaluable. But I am the only developer in a team of >100 who does.
• Groxx 6y ago
  It died without anyone caring, because good riddance. Not noticing is merely a side-effect.
• sumanthvepa 6y ago
  UML really died because modern software development is less like designing an aircraft than it is a research program to design a new kind of aircraft. To the programmer, the plafroms they are going to build on are so vast and complicated, that their behaviour is not fully known to the programmer. So to design a specific application, the programmer has to performa series of experiments on the platform to determine the manner in which it will have to be used to support the objectives of the application. When those experiments are complete, the programmer can then spend some time in design, but for the most part programming-in-the small is akin to conducting research and then doing a little desing. For large systems, someone has to do design, but the best way of doing such design is through whitepapers, and large scale experiments and possibly simulations and analysis. UML isn't particularly useful, beyond establishing a common vocabulary for diagrams -- a task that can be done more simply and informally.
  • jnwatson 6y ago
    Yep. Software development is closer to biology than mathematics now. Instead of some first principles that help us understand a system, we poke and prod it.
• anon321321323 6y ago
  Ah yes. That horribly failed project back in the day. Quoted 8 weeks to generate a requirements document and particular experimental prototypes for certain narrow areas to explore those requirements. Allowed two weeks for requirements gathering. The rest was then expected to be cycles of requirements and prototyping. This was all readily spelt out in the contract. I made the mistake of using UML. They argued about lines and shapes of the sequence diagrams for around 3 days. Then it was fonts. Then it was colors. They wanted images. They wanted all sorts of nonsense in the diagrams. But the actual content? Apparently not so important. Three weeks passed without a single line of code and the requirements gathering still wasn't complete or even approaching a first draft. I aborted it before this project had a chance to go into actual development which was the next stage and a separate contract. I learnt many valuable lessons. Including the wise counsel of having a contract with exit clauses. Thank you to the lawyer who wrote it up at relatively minor cost. The same lawyer who apparently was a waste of time according to colleagues at the time. Colleagues I later abandoned when they made other stupid decisions. Always get contracts verified by legal representation. Sounds obvious. But apparently not. UML wasn't actually the issue. I just lacked the crayons and experience to stop what would later come to be termed "bike-shedding". Because the diagrams etc were "human readable" it was deemed that anyone could have an opinion. So they did. Repeatedly. Ad nauseum. Later projects went better when I limited the size of requirements gathering and who could make changes. Experience built up and my BS detector got a lot better. But I kind of didn't mind UML as such. I actually prefer waterfall. Real waterfall is cyclic and resembles agile. But no one ever does it that way. They think it locks things in at each stage and the deliverables are like unchangeable stone tablets from on high. Ugh. So painful when done that way.
• andreskytt 6y ago
  It’s about communication. Occasionally one needs to communicate complex structures to an audience with unclear capabilities. The ability to fall back to something that one can reasonably hope is understood more or less the same way by both the writer and the reader is invaluable. If you are not dealing with complex structures or have other ways for communicating them or share another language with the reader (what do these boxes _mean_?), UML is not useful.
• deleted 6y ago
  [deleted]
• marcusalanen 6y ago
  To some extent UML did succeed: it is the de facto way to describe class diagrams, state machines etc. That's not to be underestimated. I went to university just before UML had hit it "big". For some reason we learned three different ways to describe a class diagram graphically. Let's skip the part where we don't think that belongs to the university; it doesn't. But it does show how confusing things were, even to lecturers. Now, if you were to bring me a class diagram with a completely made-up notation I'd immediately ask you to use UML notation next time. It's not a big success, but a success nevertheless.
• krasicki 6y ago
  UML is a near-deprecated aspect of what was once called Computer-Aided Software Engineering (CASE). UML became the canonic iconic notation that replaced the multitude of -cough- guru-inspired systems and software notations that preceded it. As is documented in the rest of this thread, UML belongs to the age of mainframe and mini-computer programming projects with ubiquitous RDBMS backends. While the notations it consolidated were much lighter-weight and easier to use [AND more intuitive!], UML drowned in formalizing the corporate complexity of all of them. And as if that weren't a complex enough ambition, UML attempted to do rules-based and heuristic enforcement of Object-Oriented programming just to ensure its rejection by pedestrian programming staffs. Today, its a convoluted mess that virtually no one tries to untangle in a professional setting. Intelligent IDEs and the left-shift of Dev-Ops utilities have co-opted the CASE tools lunch. For sketching, Google's Draw.IO is superior by leaps and bounds to the heavyweight, commercial drawing products. While that explains the UML-narcolepsy effect, the broader issue has always been the lack of systems and program design education. It still is important to convey system and programming information beyond the cohort of programmers. I can tell you from experience that many accountable company business actors have NO IDEA what these systems actually look like in all the important ways. What's missing is Computer-Aided Business Engineering tools.
• purpleidea 6y ago
  Yes. UML was stupid, over-complicated, unproven, horrible to work with, and if that wasn't bad enough, it was mostly people who didn't know how to code very well that advocated for it. It's been dead for a while now. Just being brutally honest.
• pyuser583 6y ago
  I’ve always liked UML, but seen it as a whiteboarding standard, rather than a blueprint for code.
• xyzal 6y ago
  I personally have adopted sequence diagrams in explaining processes to experts in non-programming fields with great success. Can't imagine using UML in daily coding practice, though.
• bebeapps1 6y ago
  As a beginner thanks I am going to try it .
• bebeapps1 6y ago
  As a new programmer I am going try this UML, thanks again for the referral.
  • captaincaveman 6y ago
    As a tip, don't try an learn every minute detail, think 20% gets you 80% of the way, the rest is probably not worth it for you, and if it is useful to clarify your own thinking that's good, but probably lost on anyone you want to communicate it with.
• lmilcin 6y ago
  The reason UML died is that most code is written by people who do not care about bureaucracy or much else than writing code. UML was borne to have a language to specify the design so that somebody else can implement it, or at very least that's how I have seen it used. But this doesn't make sense in most cases. We have learned that the more efficient way to write the software is have one person both design and implement that design. And this means the UML has been relegated to serve as documentation only. Which we know nobody likes to do and few do it. The UML is still strong in organizations that write code to order or when comprehensive documentation is formal output of the process. This has been more popular in the past but these days companies that shape our development consciousness decided (and rightly so) that developing their products is core part of their business.
• stiray 6y ago
  No UML we will not miss you. Maybe architectural astronouts will miss it, but hardly anyone else. UML was just another bad idea that wanted to reduce the complexity on business logic part but what it did in reality was: - Add enormous complexity of UML on business logic - Add enormous overengineering and complexity on "legoland" (code blocks that needed to behave by the UML spec) - Add enormous complexity on a coding part (developers suddenly were no longer aware of the whole process and were not only doing stupid mistakes but were unable to optimize what could be optimized. I was working on 200 million revenue project that was destroyed by architectural astronaut with "political connections" to upper management. At the end the whole dev. team was frustrated (those that brought the project to 200 million), top people were leaving and due to "generalization" of each "block" each feature took at least twice the time to deliver without all the overhead to actually get the conformation from UML "experts" what they actually need. The further you go from the ground, harder it is to see the details. Once you float so high in space that Earth is only a ball, all problems / complexity / people / ... disappear. But it doesnt mean they are not there. You just cant see them. You are just playing with the ball. The funny thing is that people just never learn, I bet there is a few thousands project running just now that want to do something similar as UML did.
  • dragonwriter 6y ago
    Architects that have authority over development but work at arms length from the actual developmwnenr effort aren’t UML’s fault, and haven’t gone away in the same bureaucratic environments they have always been found just because UML got less popular. They may now communicate (and force developera to communicatr with them) using diagrams with ad hoc symbology and inconsistent annotations esther than a structured visual language, but they still exist.
• potas 6y ago
  I'm a software engineer and use UML (specifically PlantUML) to produce diagrams for complex algorithms but I treat it more as a diagram tool than anything else.
• blippage 6y ago
  No silver bullet. No silver bullet. No silver bullet. As Alan Kay said, programming is a "pop culture", more interested in the latest fads. the fact that we have so many programming languages, many of them relatively recent, proves we don't really know what we're doing. Through my tinkerings with Rasperry Pi's, I began to develop an interest in electronics. I recently decided that I'd actually study a book on GCSE Electronics (not sure what the US equivalent of that is called). What it highlighted to me is that there's certain fundamental, timeless principles. Now, electronics is a relatively young discipline, but you can still go back decades. A lot of components we have now were actually available then, and ALL of the mathematical principles behind designing circuits remain the same. Programming is the strangest invention of mankind. It seems to have resisted many attempts at codification of fundamental principles.
• captaincaveman 6y ago
  It has mostly died with the current generation of engineers, due to a common problem. We tend to go to either extreme, UML all the things (model driven design), massively over specify things before you write code. Then react by saying, this thing doesn't work when you try to do non sensible tings with it, its terrible, anyone who uses it doesn't get it. The next gen of devs come along and thing its just for old folk who aren't down with the times. Meanwhile, some people who never never fell into the trap of the extremes carry on to use it when useful and in a sensible way. Perhaps even try to show some newer devs the benefits, but have to now get past these preconceptions, even though the newer guys haven't any experience. These people are now often leading large engineering groups, and often want a basic overview of designs (not to the minuet detail), and really don't care about your classes, but please give me a sequence diagram so I can see how this microservice it actually going to fit in, and show me you have thought through the state transitions of the data.
• flohofwoe 6y ago
  In a way, UML has survived in game engine "noodle graphs" (see Blueprints in Unreal Engine for instance). Those are more concerned with describing realtime data flow instead of component design, but the pros and cons are quite similar (simple things are simple, but complex things grow out of control).
• lokedhs 6y ago
  The one great thing that came out of UML was sequence diagrams. I don't recall sequence diagrams being a thing before UML, but they are actually very useful for describing interaction flows. What UML did was to provide software engineers with a common language when illustrating designs on a whiteboard. I guess there wasn't any money in stopping there, so they had to write a spec and them have very expensive software being built to support this vision.
• amai 6y ago
  RIP
• lifefeed 6y ago
  There was a nice study on this from 2013, "UML in practice", by Marian Petre http://oro.open.ac.uk/35805/8/UML%20in%20practice%208.pdf http://oro.open.ac.uk/35805/8/UML%20in%20practice%208.pdf She found that programmers don't use it and architects barely use it. My favorite quote: "There was a tendency for informants in large organizations who did not themselves use UML, or who used it selectively, to assume that colleagues in other roles were likely to use it more."
• dukeyukey 6y ago
  Don't draw attention to it or somebody might bring it back.
• Delphiza 6y ago
  $2.1 Billion - That is how much IBM paid for the acquisition of Rational Software in 2003. The "Three Amigo's" (Grady Booch, James Rumbaugh, and Ivar Jacobson) had different modelling methods and decided to "Unify". Most the the UML hype was about adoption and market penetration in order to get to an exit. Others were caught up in the hype and made some money too, such as Martin Fowler, who wrote UML distilled and went on to agile and Thoughtworks. Special mention to the now-unknown Alistair Cockburn who wrote a book and did a lot of consulting around the confusion of use cases. In today's language, Rational Rose would be the "Uber of Enterprise Modelling" and UML and RUP would be it's moat. Or something - Hacker News would be very congratulatory of their achievements. The question is less about why we don't use UML anymore (A: the three amigos got their exit), but why nothing has come along to replace it (A: it's not needed).
• jmuse 6y ago
  I don't agree with the authors use of masala as a cultural appropriation. Using 'masala diagrams' to derogatorily describe software modeling is totally unnecessary. Why not simply call them blended diagrams or milkshake diagrams or literally anything else that describes a combination of stuff. Picking masala is totally out of context and isn't productive in the year 2021, lets not associate race with opinion.
• TheMiller 6y ago
  Well, I still use some UML diagrams fairly often. Not so much for permanent or comprehensive system documentation, but to help me think through specific features or behaviors, and communicate these designs to others. I usually use a smallish subset of UML, because this usage doesn't require deep details. I did give up on WYSIWYG tools for this, though. PlantUML support in VSCode is pretty good.
  • lukaskubanek 6y ago
    May I ask you what were the reasons you abandoned visual tools?
• mcswell 6y ago
  I (I should say we) have used UML class diagrams to build object oriented systems. The class diagrams are something a reasonably sophisticated, but non-programmer, person can understand, so they can participate in the design phase. Of course there's lots that comes after that design phase, but it set the stage. In case it's of interest, the things we were modeling were bilingual dictionaries, and morphology and phonology (linguistics), all of which had a ton of structure we needed to model.