10 ms·

Why UML “Really” Died

88 points by onemoresoop 4y ago

CharlieDigital 4y ago
> Over the past two decades, though, software culture shifted progressively towards large tech-first companies and startups. I think that this is also part of the reason why there has been a shift away from design patterns (e.g. Gang of Four, Patterns of Enterprise Application Architecture): the training that it required to be a proficient software engineer 20 years ago isn't the same as it is now. No StackOverflow, no YouTube, a lot of documentation still on paper, etc. So you'd get a CS degree, read, learn, and apply the knowledge. That formula has inverted. Nowadays, you can build and learn along the way. Watch a tutorial and learn "just-in-time". But this also means that there's really no reason to get into complex topics like modeling, "formal" diagramming, and even design patterns.
- arinlen 4y ago
  > I think that this is also part of the reason why there has been a shift away from design patterns (...) There is no such shift. Design patterns are ubiquitous and more popular than ever. Some frameworks explicitly base their added value on providing a specific design pattern. A design pattern is a higher level construct. It makes absolutely no sense to claim that there's a shift away from higher level constructs when the whole point of programming is using a lower-level programming language to implement higher-level abstractions that implement our requirements.
  - GuB-42 4y ago
    I think that we may be shifting away from is a particular form of design pattern fetishism: abusing design patterns from the "gang of four", by their name, usually in Java. For example, you will find plenty of classes with names like "StuffFactory", implementing the "factory" design pattern, even though you may not need a factory in the first place. Design patterns still exist, and will always exist, but there I feel there is less of a tendency to use mindlessly use everything from the book.
    - CharlieDigital 4y ago
      The point of using it by the book is that we can talk about it with a common nomenclature.
      - P5fRxh5kUvp2th 4y ago
        That's backwards, the point of the GoF book was to document common patterns employed across teams. There was never any intent that you use a design pattern so you can talk about it, that's backwards.
        bluGill 4y ago
        The point of documenting what is in common use so we can talk about it. If we don't talk about it then we don't need documentation.
    - arinlen 4y ago
      > For example, you will find plenty of classes with names like "StuffFactory", implementing the "factory" design pattern, even though you may not need a factory in the first place. This assertion makes no sense. A factory is just a function whose responsibility is to instantiate an object. The GoF book then presents two types of factories that fit a specific problem domain. Is this irrational hatred of design patterns so irrational that even leads people to advocate they do not need to instantiate objects?
      - GuB-42 4y ago
        You can instantiate objects with a simple "new", you don't always need the extra level of indirection the factory class provides. Technically, "new" is a factory, but that's not what I mean, what I mean is a class that is named xxxFactory, that has a method that take something as a parameter and returns an object based on some parameter. Or even worse, the xxxFactory is an abstract class for the "real" factory, with names like "Abstract" and "Concrete". Of course, design patterns are useful, they don't come out of nowhere. And I think it is essential for developers above a certain level to know them, and recognize them by name. The issue I have with what I called "design pattern fetishism" is that: - Design patterns are typical solutions to typical problems. What some developers don't get is that if you don't have the problem, you don't need the solution. Most design patterns are about adding levels of indirection "the right way", which is sometimes necessary, but indirection has a cost, in performance, in clarity, and in development effort, don't do it if you don't need to. And I agree that it takes experience to know when you need to, that's why I think abusing design patterns is mostly the result of well meaning, well educated, but inexperienced developers. - Naming objects with their design pattern sometimes makes sense, but in other cases, I think it is a bit like Hungarian notation. You often end up with bloated names describing how you implemented a solution rather than what the thing really is. Again, not a clear cut thing, and naming things is hard, but I find some correlation between code full of design pattern names and hard to follow code (even though what the code is doing is not that complex). - Side note: singletons are global variables and shall be treated as such.
  - CharlieDigital 4y ago
    I work at a startup with former Amazon engineers in the mid 20's and early 30's. Never seen so many Helper and Util classes with static methods dangling around. Basically no thought at all given to design patterns. Design patterns are of course still a thing and very common in core libraries, but majority of the devs I've worked with over the last year (across 3 startups building full stack) would be lost if I started talking about Visitor and Chain of Responsibility.
    - bluGill 4y ago
      Design patterns make the most sense after a few requirement changes. Startups don't have that yet and think getting to market is more important than staying in the market for long.
      - arinlen 4y ago
        > Design patterns make the most sense after a few requirement changes. No. Design patterns are higher level programming constructs. The need to use and discuss things in terms of higher level constructs does no arise midway through. Or do backend developers only start to talk about controllers and views and dependency injection and singletons after Product changes their mind on something? Absolutely not. > Startups don't have that yet and think getting to market is more important than staying in the market for long. This personal assertion makes no sense at all, and casts doubt on whether you have any idea of what a design pattern is. Your comment reads as a a stream of cliches tied together that have no meaning.
        bluGill 4y ago
        > Design patterns are higher level programming constructs. The need to use and discuss things in terms of higher level constructs does no arise midway through In part it does. You can hack things up quick without thinking intentionally about higher level constructs and it will all work. When you want to maintain your code for years, then you need to get those constructs in the right place as an intentional act. Sometimes you will put in the right design pattern anyway, but often you won't have them in. Note that this is about the discussion and intentional decision to use patterns. You will of course use design patterns - the difference is getting the right ones in the right place. That takes experience and upfront thinking of a type that startups often do not allow time for. It may well be correct for a startup to not allow time to think about the right patterns overall. It is a decision that will come to haunt them if all goes well, but they got to market sooner. If thing don't go well (a common case), it was less money spent finding that out.
- monksy 4y ago
  It's not just the resources we have today, in yesteryear we had the MSDN that had an annual subscription and release, we had more books etc. Today, there are promotions and aggressive business fighting of formalization within our field. People who slow down and plan out systems have been weeded out of organizations. People who make things and "ship" quickly are rewarded. This has been the same with quality control in software, and even goes down to bad developers refusing to unit test. Time to being promoted has shortened as well. Now it's not unusual for a dev to be a senior within 2-3 years. Lead in 5. That's just the start of their career. I haven't heard the last time that the title "Jr" was used. > Build and learn along the way It's always been that way but you had a lot more oversight from people that were much more senior.
- Fiahil 4y ago
  > I think that this is also part of the reason why there has been a shift away from design patterns Citation needed. I see, use and teach design patterns every day, and I work with Data Scientists.
  - Rexxar 4y ago
    He needs a citation to say what he thinks ?
- q-big 4y ago
  > So you'd get a CS degree, read, learn, and apply the knowledge. > That formula has inverted. > Nowadays, you can build and learn along the way. People's opinions by now differ byt a huge amount whether this is a good or bad/dangerous trend.
ShuffleBoard 4y ago
Meh UML was always the Sun Chips of the software world. https://www.theonion.com/sun-chips-abandons-biodegradable-bag-1819560705 https://www.theonion.com/sun-chips-abandons-biodegradable-ba... "Are you kidding me? I crafted my entire freshman year persona around being the 'Sun Chips Asshole.'" PAUL KENEMORE • STUDENT
riedel 4y ago
Posted 1 year ago: https://news.ycombinator.com/item?id=26956298 https://news.ycombinator.com/item?id=26956298 Also interesting is the linked post: https://news.ycombinator.com/item?id=26934577 https://news.ycombinator.com/item?id=26934577
andrewstuart 4y ago
I hated UML because it felt like someone "very important" had issued a commandment from that unless you did software with UML then you were DOING IT WRONG (spoken in a booming voice from the sky). It felt super academic and "Thoughtworks"ish and Javaish and made software development boring instead of dynamic and fun. Glad its gone.
- 29athrowaway 4y ago
  - deleted 4y ago
    [deleted]
  - zozbot234 4y ago
    I'm not sure where this notion of UML diagrams as a silver bullet against technical debt is coming from. The whole OOAD development methodology that UML adoption was predicated on is the opposite of serious or rigorous; you can't just translate domain-level "objects" into a design and expect to end up with something sensible, that's not how it works. (In fact, unless some well-defined part of a system really has meaningful invariants that it cares about and should preserve, there's arguably not much of a real reason to even make an "object" out of it.)
    - im_down_w_otp 4y ago
      I tend to agree with this. If UML or something UML-like offers value in terms of understandability at some level of abstraction as a substitute for needing to hold the detailed mental model of the entire explicit implementation in one's head, then using it as something extracted from the implementation to provide a simplified sketch of it makes more sense than using it as an input artifact to creating the implementation.
    - 29athrowaway 4y ago
Thetawaves 4y ago
I considered the explanation was simply that diagrams created in UML are unreadable to lay persons. Excessive use of visual jargon, and changing standards combine to make everybody a lay person, even those versed in a particular version of UML when confronted with a different version.
- 29athrowaway 4y ago
  They are pretty trivial to understand.
  - IshKebab 4y ago
    I agree with him. They always had like 5 different types of arrow that had various easily forgettable meanings.
    - Thetawaves 4y ago
      Not just forgettable, but vastly different meanings. And these meanings have changed between versions. You really have to get close to the spec to grok what is actually being conveyed.
  - Macha 4y ago
    The devil is in the details - if you have to understand the details like the right arrows for relationship types and visibility modifiers, then it gets much less trivial. And if you're going to omit those details, then do you really need a standard for your adhoc boxes and arrows diagram?
    - 29athrowaway 4y ago
      You can add a legend at the side of the diagram, problem solved.
29athrowaway 4y ago
Sequence diagrams are still widely used. Use-case diagrams should be used more. Class diagrams are good to reveal poor OOP designs.
kieranmaine 4y ago
UML may be dead but I still use sequence diagrams. They're great for visualising complex code and systems, especially if you're new to a system and are trying to gain an understanding the flow of data. I've used mermaid and plant UML and both seem to powerful enough for my use cases, especially when used in conjunction with the preview mode in VS Code.
- jmfldn 4y ago
  Was messing with mermaid and state diagrams only today. I don't use UML as a whole but some of the diagrams are really useful.
- chowells 4y ago
  Sequence diagrams are great. Any time there's a multi-stage interaction with multiple independent pieces involved, they're hard to beat for communication. It's not like UML was based on bad ideas. There were just too many cases where the added value was less than the added cost. But when a diagram does add net value it's great to have conventions already.
- xh-dude 4y ago
  Oh, mermaid looks nice! I hadn’t seen it before. Thanks for mentioning it. If UML tooling had just focused on diagrams, I would not revile UML.
- marcosdumay 4y ago
  Entity relationship models are good, but people will disagree whether they are UML. Sequence diagrams are useful, but the UML version with a vertical diagram with horizontal lines optimizes for the least necessary use cases; also, the UML one has no space for the participants states. Use cases diagrams are useful, but the UML version just wastes all the space and takes all the useful information out (well, it keeps the actors, could be worse). Class diagrams aren't very useful at all, and when you need them you don't need the formality that is the main point of UML. And finally, the UML designers failed to include any data transformation diagram, because they really did only think in procedural terms.
pipeline_peak 4y ago
UML is too formal for the quick and dirty world of low profile software projects. In whiteboard examples, most people tend to come up with their own “dialect” of UML relational graphs anyway. Not to mention the ease of defining skeleton classes. UML is too trivial to be a standard, feels like a byproduct of the 90s OOP craze. As long as it gets the point across, who cares?
- lokedhs 4y ago
  You're definitely right about that. Most people think of UML as a notation for relationships between components, and it's useful to have a syntax that people can agree on so it's clear what you're drawing on the whiteboard. But you don't need a 750 page (really) standard creating a formal specification of this syntax. Just in case people don't know just how formal the specification is, here's part of the explanation of event dispatching: As discussed in sub clause 13.2.3, a Behavior execution always has an associated context object (which may be the execution itself). A context object mediates the handling of Event occurrences for all of its associated Behavior executions. When an Event occurrence is recognized by a context object, it may have an immediate effect or it may be saved for later triggered effect. An immediate effect is manifested by direct invocation of a Behavior as determined by the Event, such as the invocation of the method of a BehavioralFeature (see sub clause 13.2.3). A triggered effect is manifested by the storage of the occurrence in the event pool of the object and the later consumption of the occurrence by an ongoing Behavior execution that reaches a Trigger that matches the Event corresponding to the occurrence in the pool
flarg 4y ago
Controversial opinion incoming ... The people who should use UML are too lazy to learn it and instead draw weak abstractions in PowerPoint or C4. Those people are business analysts/requirement engineers/product owners. The true value of UML is that it reduces ambiguity and constrains risk through lightweight prototyping. Wireframes do the same thing. But not one PO can resist writing reams of non descriptive text and drawing impossible data flows. Developers are not the people who should draw UML.
- ok_dad 4y ago
  Imagine telling a site construction engineer that not only does he have to manage the construction, but he has to develop the blueprints and also become the office manager once the building is done.
  - zx8080 4y ago
    > Developers are not the people who should draw UML. > Imagine telling a site construction engineer that not only does he have to manage the construction, but he has to develop the blueprints... Okay.
  - somat 4y ago
    The code is the blueprints. The running program is the site. Under this metaphor the construction engineer is the compiler. But yeah I feel the office manager bit, that hits close to home.
    - xboxnolifes 4y ago
      Code may be the blueprint for the program, but UML is still the blueprint for the code.
    - cma 4y ago
      > Under this metaphor the construction engineer is the compiler. What about for interpreted languages?
mhd 4y ago
I do miss the Booch cloud diagrams, they brought a bit of whimsy to OOD.
matt_attack 4y ago
If only it was dead. It's still alive and kicking in military development environments pushed down from above by management.
spamizbad 4y ago
> Ernesto Garbarino says that UML was killed by decreasing standards among programmers: “Agile was the assassin and user stories were her deadly, poisonous arrow heads (pun intended).” I got my start in a shop whose CTO was a big believer in UML. I can tell you unequivocally that software processes from that era, while providing some useful lessons, were a result of the 90s software engineering Zeitgeist, which included these major aspects: 1) Non-technical management was still regularly involved in the management of software engineering and engineers needed to explain “Here’s how we will do X” to laypersons 2) Object Oriented programming was at the peak of its hype cycle, but most of the software development workforce had a superficial understanding of it at best. UML allowed you to explore a problem in an object oriented manner before writing any code and gave more OO-savvy engineers the ability to communicate these concepts to other developers who had no hands-on experience writing object oriented code. 3) The “style” of object oriented programming advocated back then would probably get your hand slapped during any modern code review… even by relatively junior developers. 4) Lots of software development practices we take for granted today were not universal: source control, fast build turn-arounds, automated testing. Likewise, because software was delivered via physical media and your ability to distribute patches was far more challenging the whole process was fundamentally more conservative. So to bring this full circle, what changed since UML’s heyday? 1) Software engineering as an institution matured to the point where almost the entire management chain will typically know not just how to code but actually ship software (seed stage startups are an exception here) 2) Object Oriented programming hype has died down. It turns out it wasn’t the productivity boon we imagined (garbage collection and open source libraries did more for us) 3) Stronger and more robust type systems, Functional programming concepts, and unit testing methodologies are used to mitigate defects 4) Turn-around time to distribute a fix for a production defect is measured in minutes or hours - not weeks or months. 5) Things like CI/CD exist which would’ve made a 90s developers head spin.
- katdork 4y ago
  other developers who what?
  - spamizbad 4y ago
deleted 4y ago
[deleted]
bfung 4y ago
Some UML diagrams are still super useful. The real problem is that the parts of the ecosystem is over engineered and targeted to the wrong audience. For example, Class diagrams, sequence diagrams -> useful for debugging or for implementation, but very bad for product specifications. If the Product person could write class diagrams, they could probably just implement the system themselves. On the other hand, if a programmer was given a class diagram, they'd still need to figure out if the design/diagram was correct to solve the problem they're given. On the other hand, a couple of market-tecture (architecture/systems diagram but made easy to understand to even sales people) was drawn, with some useful descriptions of what the whole system did, people/teams can be assigned to fill out the details, and measure their performance against the constrained problem.
Existenceblinks 4y ago
[Rant] The class in university I hate the most is "Software Engineering" because it doesn't sound like engineering at all. They taught UML, Waterfall, Sequence, ER Diagram, and all useless stuff that I never use within 10 years in software industry.
- deleted 4y ago
  [deleted]
- icedchai 4y ago
  Sequence diagrams are very useful for APIs and understanding protocols between systems. ER diagrams are great for presenting a database schema (just don't get too hung up the exact arrow you're using!) When I start a new major project, one of the first things I do is an ERD. You don't need every field (column, attribute...), but the tables (entities, objects, collections, whatever you want to call it...) and their relationships are pretty important.
  - tyurok 4y ago
    Yes but it seems the order is taught is important. Without actual industry experience, it never occurred to me it could be useful. After some years working, it's clear it's useful in some capacity but it's easy to overdo it (like require every detail of the system to be in those formats) or misuse it (sequence diagram improperly documenting async flows).
  - billfruit 4y ago
    I think statecharts are even more useful than sequence diagrams in documenting behaviour. Statecharts are Turing complete, and succinctly visually encode complex behaviour that is going to take reams of text to describe. Harel et al have done serious, rigourous work in developing statechart.
  - Existenceblinks 4y ago
    As I remember ORM / NIAM diagram is more superior that it can turn into 5NF in one go (or two .. can't remember exactly) I find it's easier to think of these data as cartesian product of a bunch of tuple. Even having table in my imagination is confusing!
icedchai 4y ago
I find some aspects of UML, mainly sequence diagrams, useful. Other aspects, like class diagrams, not so much. Plain old boxes-and-line drawings are usually enough. UML was associated with big upfront design, and basically died with "Agile." Why design anything when you can fix it in the next sprint?
ncr100 4y ago
It is useful, and can be overused. I find many software engineers, including myself, have a hard time communicating coherently and specifically the detail of their plans, in my years as a SWE in the fun-startup-space I've enjoyed working. There are ambiguities embedded in many design challenges, and they interfere with UML has been a great way to talk about parameters, data flow, and ownership. I use it for bits and bobs of the conversation, and to help break down problems for distributing the work amongst team members. I don't pre-plan entire projects with UML, though that could be influenced more by business-requirements than the pros and cons of UML.
mark_l_watson 4y ago
Good article, nails a lot of stuff. Before UML, Grady Booch sent me a rough manuscript of his future book Object-Oriented Analysis and Design. I used his diagram style in a C++ book I wrote for McGraw-Hill (I don’t think my book was very good, in retrospect, but the diagrams were nice). A few years later I co-wrote a UML for Java Developers book. Then for years at work I just sparingly used my favorite Sequence Diagrams and a few Class Diagrams - nothing else. In the last 20 years I have just used Sequence Diagrams, and I still like those. Pardon something off-topic, but I would appreciate opinions on this: since we are talking about tidy old fashioned practices vs. agile development, I used to hate full on code reviews, but I enjoyed and thought the lighter weight practice of code walkthroughs or even just having two people read through a code module and fill in a questions form. The author(s) answer the questions, everyone talks a bit, and in the end, reviewing a perhaps 500 line module might take up a total of 3 hours of engineering time - and more people understand more of the system that they are working on if this is done frequently with many combinations of people.
didibus 4y ago
I think the issues with UML and any technique of top/down design is that it doesn't recognize the bidirectional influence of design. The interface influences the implementation and the implementation details influences the interface. Similarly, the whole influences the unit, and the unit influences the whole. You can only design working software if it takes into account both directions, software design has to simultaneously take into account top/down and bottom/up concerns. I think people realized this, and so when you start, it makes more sense to only have a rough top/down draft of the design, since once you implement you'll need to refactor the design anyways from the concerns that appeared from the implementation details. UML therefore became a waste of time, since half of it would change anyways by the time the project shipped.
- P5fRxh5kUvp2th 4y ago
  I agree with your point, but I don't know that I'd blame UML for that, I'd blame people. It still happens today without UML, it's just moved from flow diagrams to powerpoint and word presentations.
- bluGill 4y ago
  I worked briefly for a place that generated code from UML. The code itself was ugly C++, but I never looked at it so who cares. Every week the first thing I did was print out the UML on large paper and paste it on my wall. It was nice to see everything on my wall like that, but just one week of one programmer time and what was on the wall was already obsolete in some critical way. One important part of UML is the layout. Every week I.made a minor tweak to how the boxes were on the page so things looked nice. Every few months a larger change to layout. Since then I've been to a lot of places where people ask for UML, but since there is no way to synchronize the code and UML the UML is left to rot. We could keep it up to date and i'd love it, but that means one full time graphical person for every two developers. I don't think UML is worth it unless it is the code.
mrleinad 4y ago
How do you explain an architecture to other developers?
pamelafox 4y ago
I still find it helpful to use UML diagrams in a classroom setting when describing a project codebase at a high level. For example, this slide diagrams some classes used in a Scheme interpreter: https://inst.eecs.berkeley.edu/~cs61a/sp22/assets/slides/30-Modularity.html#/24 https://inst.eecs.berkeley.edu/~cs61a/sp22/assets/slides/30-... (Generated with PynSource) I also find such diagrams useful in an engineering setting when explaining a codebase or design decision to teammates.
_8j50 4y ago
Would a short description of UML at top hurt. Here I am trying to figure out how thid related to user mode linux. I stopped mid way and had to read comments. Either way, didn't know UML died, visio still supports it right?
- dzdt 4y ago
  Same. User Mode Linux was my guess; the first paragragh of the article was enought to tell me that was wrong but gave no hint of what the acronym might mean, not even broadly. I had to google : it is actually about Unified Modeling Language diagrams of object classes and their relationships. I guess nobody who uses UML diagrams ever thinks of UML as an acronym?
isthisthingon99 4y ago
UML is not dead, I use UML diagramming all the time. As with anything, you want to be judicious in your use of it. Edit: shoutout to https://plantuml.com/ https://plantuml.com/ for making me the coolest kid on any new team.
- ttfkam 4y ago
  Seconded! You can have my PlantUML when you pry it from my cold, dead hands. Once I was shown diagram source you can diff between revisions, I was sold.
buescher 4y ago
UML statecharts are great, but I’ve not yet used them end-to-end and I’m not mourning the passing of UML-driven OO methodologies.
FpUser 4y ago
I use ER diagrams, Sequence diagrams, State machines, Use case diagrams etc during planning design stages and find it really helpful to capture business processes / requirements and turn those down to a rough design. Except trivial cases (of which I admit we have plenty) thinking before piling up code has great value. What did die is insane approach preached by fanatics in Rational. Now we have the same situation with Agile / SCRUM. I hope this abomination (the way it is being forced down everyone's throat) suffer the same fate. The other related subjects are / were - everything has to be, OOP, OOP sucks, let everything be pure functions and other crap like this. Luckily I've avoided all the propaganda and sticking to "the only true religion" never mind that new new one would come out every other year
pxtail 4y ago
When UML concept was introduced to me at university I was astonished by it and thought that it's really brilliant - I perceived it as parallel concept to construction and architectural blueprints. I noticed how it helped to plan software development, spot hidden issues, missing functionality, revisit functional requirements with general design of software before even trying to write any code - it also was obvious for me that it is a tool for people with a lot of experience under the belt, aware of best practices, possibilities, common pitfalls etc. I really liked whole concept, I'm sad that it isn't common practice now - probably just too expensive to do instead of just bashing keyboard buttons and stitching together some libraries However I think that it will return in some form at some point - software as a craft is incredibly young compared to for example construction AND "everything old is new again" is incredibly popular in this field of work ;)
cartoonfoxes 4y ago
Despite being mostly a subset of UML, SysML is a more cohesive and useful design and modeling tool. Unlike UML, I've actually used SysML on real embedded systems projects and like it. It lends itself well to model refinement, wheras UML encourages Big Design Up Front. I'm not sold on the idea of capturing an entire design within SysML, but using it instead as a diagram format with defined semantics for situations where group discussion or communication with third-parties calls for some graphical aids. I think as long as you're not trying to make executable models, do code-generation, or replace a formal specification tool like TLA+, there is real value in it. The documentation and training ecosystem around it is pretty decent, as well. The SysML books I've read have all been way more pragmatic and grounded in actual engineering practice of building systems from many components sourced elsewhere, for which design capture is necessarily incomplete.
- kejaed 4y ago
  What tool did you end up using for SysML?
  - cartoonfoxes 4y ago
    Currently, I'm not currently working in a dedicated modeling tool at all - just draw.io. We started with Enterprise Architect from SparxSystems - it's a bit janky and covers a lot stuff beyond SysML, but it works fine. Cameo Systems Modeler is good too - it omits the non-SysML garbage that the other platforms include, and has the best Model-to-Html rendering I have seen, but was double the cost of EA so did not use it for work. The open source tools, Modelio etc. were all a broken waste of time. For my use, there is a sweet-spot for "models" spanning only a handful of diagrams (5-10) where any drawing software with SysML templates will do. The dedicated modeling tools like EA or Cameo become relevant once you're trying to keep model elements consistent across a large number of diagrams. Draw.io is free so the whole team can use it, and the the lack of model representation keeps diagram count low and not over-specified. Cool products, btw.
bane 4y ago
UML came up a few times during my CS program years ago. I found it kind of infuriating at the time since it just seemed to be an idea vacuum cleaner that sucked up so many different diagramming ideas into one place and stuck somebody else's name on it -- plagiarism at an enterprise level. I've grown to somewhat respect it to a point as a formal way of documenting a system, but goodness no, would I never ever design a system with such cruel intent.
neilv 4y ago
As someone who learned and used a lot of the methodologies before UML, and developed CASE tools for some of it, looking at discussions of UML are painful, for two reasons: 1. It seems that almost everyone commenting has seen only bad uses of UML. Even before UML, there've always been people who used modeling tools without understanding them, there've always during OO era been people who really only wanted to see a class inheritance hierarchy, and knowing when to use the models and when to code or do other things is an art like much of the rest of software development. We've got a lot of people writing one-star Amazon Customer Reviews for a screwdriver, who've never seen a screwdriver used properly, and only know hammering. 2. When I try to use particular models and views of UML myself, the documentation and tooling I find in the time available borders on unusable, and I end up improvising what I need. Given that I know a lot of the influencing methodologies, and I've even developed tools myself, if this now looks like crazy enterprise sales&consulting cash cow nonsense to me, then I can't be surprised if other effective software engineers are turned off by what they see. But that's sad, because the value is there, just obfuscated.
- thematrixturtle 4y ago
  This argument sounds very much like "the problem is not communism, all those countries just weren't doing real communism". And I'm not even being quite as flippant as it sounds about communism here. Communist economic planning relies on accurate central planning, which we've learned the hard way is essentially impossible at the scale of a nation state. In the same way, UML assumes you can meaningfully model a complex computer program in advance, which tends to fall flat back in reality where requirements are poorly understood and evolve continuously.
  - cyanydeez 4y ago
    I think the most coherent argument for failure is the limited automated feedback between real code and the uml
  - neilv 4y ago
    I don't know enough about communism to make analogies there. I do know that there are successful uses of screwdrivers, and that a screwdriver makes an ineffective and dangerous hammer.
zmmmmm 4y ago
I think the biggest one is the "rot" problem. Software iterations have gotten faster (in general, not just due to agile) and it just seems pointless documenting things separately with diagrams when so often they have a short lifetime of accuracy. Then, not having a good text representation means it does not play nicely with version control which compounds it all (how can you get the right version of the diagram for the specific software). It did not help at all that the UML tools were typically expensive so only the ivory tower architects would have them so most of the team couldn't actually edit the UML. I do remember a phase where I used TogetherJ extensively as a full round-trip UML tool. It very nearly worked to the point where I could edit things on the UML diagram and the dive into edit the individual classes and methods in code. PlantUML has done a lot to help with this for our team. The slowly evolving convention of embedding PlantUML/Mermaid into Markdown and / or code comments is starting to enable a more maintainable / agile way of doing this. In particular have found Znai recently as a nice tool that brings all of this together along with code extraction to make nice "user manuals" comprised of documentation in markdown format and code comments.
bitwize 4y ago
Ah, UML. You were positioned to replace programming altogether in the early 2000s. We were told there would be no need for programmers when you can just turn a crank and get Java generated from UML diagrams. And CASE! The low/no code of the 80s! How the mighty have fallen. Important things to bear in mind when considering this era's silver bullets...
qiller 4y ago
We had a ton of formal modeling classes back in college, but about the only two concepts that stuck with me and still being used when we need to document something are the UML sequence diagrams and a somewhat less known IDEF0 activity diagrams - https://en.m.wikipedia.org/wiki/IDEF0 https://en.m.wikipedia.org/wiki/IDEF0
Rochus 4y ago
> they bought Jacobson’s consulting company and phased out OOSE The method and tool by Jacobson and colleagues was actually called Objectory, not OOSE (the latter is the name of a german consulting company which pubished their own method called OOSE more than two decades ago). Objectory as a method and tool was excellent, especially for analysis and design. Rose (the Rational tool) might have looked prettier than the Objectory tool but couldn't do much more than diagram drawing. Unfortunately the Objectory tool vanished after they bought it. UML and RUP have suffered the same fate as all methods. After a certain time in evolution, people have forgotten the original intentions and concepts, watered them down beyond recognition or diverted them from their intended purpose, and instead only formalistic but useless rites are practiced, which is commonly referred to as cargo cult. The same fate will happen to Agile (or it has already happened).
- jdougan 4y ago
  Object-Oriented Software Engineering is the title of Jacobson's 1992 book describing a reduced tool-less version of Objectory that was referred to as OOSE. ISBN 0-201-54435-0 To this day I still use OOSE notation when sketching a design, I alwas thought UML was a step down.
  - Rochus 4y ago
    You're right, the book does not present Objectory, just the fundamental ideas. But RUP was the continuation of the "Rational Objectory Process", which was Objectory gradually using UML instead of the original diagrams. The fellow referred to Jacobson's consulting company and RUP and UML, not Jacobson's text book. I still have the original Objectory documentation, and even asked Jacobson many years ago whether they could open source the Objectory tool, but unfortunately that didn't happen yet (at least not to my knowledge).
mbfg 4y ago
I think IDEs killed UML. You can look at a model and understand a system, then try to translate that to a code base, and try not to lose anything in the translation. Or you can just use an IDE and find all these things that UML tells you directly on the code base, and do no translations.
packetlost 4y ago
If you can't break down your systems model into a subset of inputs, outputs, and domains (which can be broken down even further to whatever degree of complexity necessary), someone probably doesn't fully understand their system very well. Yeah, UML is chunky, but the ability to identify the high-level goals of a system allows you be be focused on how those systems should behave and the rest is just meeting that spec reliably (or within whatever margin of error is determined to be appropriate). If things are truly inter-dependent, the ability to identify risk points as a high, abstracted level is invaluable.
globalreset 4y ago
It died because it's stupid and useless.
osigurdson 4y ago
The industry has always wanted to have a small number of smart people creating designs which can be handed down to a large number of dumber people to implement. We can't seem to accept that it doesn't work that way. That being said, UML isn't horrible, it's just fundamentally unimportant.
nitwit005 4y ago
One thing that changed was just scale. Many visual representations of information are great, up until a certain complexity, and then people can't tell what they're looking at. A coworker demoed some Rational product to us back in the day. It was very impressive, creating class diagrams from existing code. It was also an incomprehensible mess of nodes and edges.
dqpb 4y ago
UML conflated system modeling with diagramming and focused too much on the diagramming.
KronisLV 4y ago
> I wouldn’t expect two teams in different companies, one in California and the other in New York, to use similar notations unless someone was deliberately keeping them in sync. I feel like you need a reference implementation for almost any spec out there for it to remain consistent, like a tool that everyone might use for working with UML or whatever. For example, have a look at BPMN, which has https://bpmn.io/ https://bpmn.io/ without which it would be another spec that many wouldn't care about. Of course, the tools actually need to be good, because I've seen too many bad Eclipse based pieces of software, like for 4EM modeling or other approaches that never really took off in the real world, outside of niche contexts. It might be a case of model driven development feeling pretty useless, unless it actually helps you develop the solution with minimal friction. A good example of this are ER diagrams in MySQL Workbench! For example, consider the following, what I've sometimes done: - open MySQL Workbench - reverse engineer an existing DB, get an ER model - alter the model as necessary (add tables, change columns etc.) - use the forward engineering/synchronization tools to get DDL that could be applied to DB - execute or alter as necessary beforehand Contrast this to the workflow that a colleague of mine had: - open draw.io - open a manually drawn ER diagram of the DB from local/shared disk - compare against DB schema manually, possibly fix parts that have changed in the DB since last diagram update - alter the model as necessary, using regular drawing elements and text (with lot of it being more like working in Paint) - once happy with this "documentation" and it looks good, manually write all of the SQL that's needed for migrations - execute the SQL I think the best kind of documentation and models is the one that doesn't lie to you (can be updated automatically) and tools that integrate with what your infrastructure/application/schema actually is supposed to be, rather than some out of sync model. Otherwise you end up with documentation that is wrong or that nobody cares about. If you want something like UML or any other modeling approach to be popular, I'd argue that you'd need something like the following: java2uml --in-package src/java/main/dev.kronis/sales_app_2022/products --out-model products.uml "MadeUpSoft UML Studio" > File > Open > products.uml ... do your changes "MadeUpSoft UML Studio" > File > Save uml2java --in-model products.uml --out-package src/java/main/dev.kronis/sales_app_2022/products Until we have model driven development that goes both ways (forward and backward engineering), the use cases for it will be severely limited.
- ttfkam 4y ago
iLoveOncall 4y ago
People that think UML is dead are people that work in companies with terrible engineering practices. I haven't been in a single decent team that didn't use UML to some extent for designing components. I just don't see how you could do a design review with your team without using UML.
specialist 4y ago
Many great points made, both the OC and in these comments. Another methodology pitfall (in general, not just UML) was working with other humans. It's just so hard to get everyone onto the same page. Just one tiny facet of UML are use cases. I love the book Applying Use Cases: A Practical Guide. Short, precise, actionable, repeatable. It's basically just a recipe. Almost too easy. TLDR: All architecture must be tied back to use cases. No brainer, right? My company did a lot of continuing education. So we all read Applying Use Cases, have multiple bookclub style discussions, try to use the methodology during a project kickoff (bridge from requirements analysis to high level design). Holy shit. You'd think we all had read different books. There was no shared understanding for any of the concepts, how to proceed. All normal pedantry (defining "use case", arguing over system vs user, correct level of abstraction, questioning the requirements). Plus the new arguments about tracing "use cases" to "architecture". FWIW, that was the effort that broke me. After a few years of being a methodology warrior, I just gave up. At work, I want to ship code, not debate philosophy with bozos. I still use various OOA/D techniques and skills I've acquired. But only for my own benefit. Either I'm in a position to just tell people how it's gonna be. Or I keep my mouth shut. Fortunately, XP and Agile popped up. Enthralled all the poseurs and PHBs. Leaving me (and my teams) alone to just focus on shipping product.
scioto 4y ago
Peer pressure led me to purchase The Unified Software Development Process, The Unified Modeling Language User Guide, and Fundamentals of Object Oriented Design in UML, and while I tried to read them and understand what they were trying to accomplish, I realized that putting ideas and concepts and flows into formal diagrams with rules to argue with others really wasn't getting me or my group anywhere. So we went back to whiteboarding and mostly doing top-down design (using decomposition to get down to actual data flow), and we got our products out the door. In the meantime those books took up space on my shelf and ended up being more for impressing people who walked into my cubicle (remember cubicles?). Now in my home office two of the three are makeshift monitor stands. I'm finally going to try to dispose of them somehow without harming the environment. I think they're recyclable.
mejutoco 4y ago
IMO UML died because it was too coupled to OOP (maps directly to objects/classes) and it is (like most visual languages) a more verbose version of the textual version (probably Java classes/interfaces). Of course it is still useful to communicate an idea, but so is a diagram or an MVP (maybe with some formal guarantees from the type system or a TLA-like "proof")
makeitrain 4y ago
Just take a picture of the whiteboard with your phone and upload to jira.
dwaite 4y ago
We did quite well back in the day with the "UML as blueprints" approach, and I personally felt that for new complex systems that mapping between various diagrams and the use cases helped greatly in clarifying a larger OO system before we started writing code. I felt creating diagrams and getting consensus at the start of iterations made us significantly more productive and produced better results. But most active tooling and education for UML was always CASE-oriented, which was way too heavyweight for such a small org. I would use more "UML for sketch" tooling - like OmniGraffle with good (internal) stencils - which allowed for iterative improvement to the diagrams. I actually switched from Linux to Mac for OmniGraffle. Invariably the UML tooling of the day was too cumbersome, because it was geared toward making more formal models from the outset. It is the UML sketching which I have kept throughout my career, and lamented that as CASE died, there hasn't been anything else to supply baseline education nor has there been any evolution (or simplification, or unification.) I suspect creating such things just isn't that attractive without the CASE money being there.

88 points by onemoresoop 4y ago

> Over the past two decades, though, software culture shifted progressively towards large tech-first companies and startups. I think that this is also part of the reason why there has been a shift away from design patterns (e.g. Gang of Four, Patterns of Enterprise Application Architecture): the training that it required to be a proficient software engineer 20 years ago isn't the same as it is now. No StackOverflow, no YouTube, a lot of documentation still on paper, etc. So you'd get a CS degree, read, learn, and apply the knowledge. That formula has inverted. Nowadays, you can build and learn along the way. Watch a tutorial and learn "just-in-time". But this also means that there's really no reason to get into complex topics like modeling, "formal" diagramming, and even design patterns.

arinlen 4y ago
> I think that this is also part of the reason why there has been a shift away from design patterns (...) There is no such shift. Design patterns are ubiquitous and more popular than ever. Some frameworks explicitly base their added value on providing a specific design pattern. A design pattern is a higher level construct. It makes absolutely no sense to claim that there's a shift away from higher level constructs when the whole point of programming is using a lower-level programming language to implement higher-level abstractions that implement our requirements.
- GuB-42 4y ago
  I think that we may be shifting away from is a particular form of design pattern fetishism: abusing design patterns from the "gang of four", by their name, usually in Java. For example, you will find plenty of classes with names like "StuffFactory", implementing the "factory" design pattern, even though you may not need a factory in the first place. Design patterns still exist, and will always exist, but there I feel there is less of a tendency to use mindlessly use everything from the book.
  - CharlieDigital 4y ago
    The point of using it by the book is that we can talk about it with a common nomenclature.
    - P5fRxh5kUvp2th 4y ago
      That's backwards, the point of the GoF book was to document common patterns employed across teams. There was never any intent that you use a design pattern so you can talk about it, that's backwards.
      - bluGill 4y ago
        The point of documenting what is in common use so we can talk about it. If we don't talk about it then we don't need documentation.
  - arinlen 4y ago
    > For example, you will find plenty of classes with names like "StuffFactory", implementing the "factory" design pattern, even though you may not need a factory in the first place. This assertion makes no sense. A factory is just a function whose responsibility is to instantiate an object. The GoF book then presents two types of factories that fit a specific problem domain. Is this irrational hatred of design patterns so irrational that even leads people to advocate they do not need to instantiate objects?
    - GuB-42 4y ago
      You can instantiate objects with a simple "new", you don't always need the extra level of indirection the factory class provides. Technically, "new" is a factory, but that's not what I mean, what I mean is a class that is named xxxFactory, that has a method that take something as a parameter and returns an object based on some parameter. Or even worse, the xxxFactory is an abstract class for the "real" factory, with names like "Abstract" and "Concrete". Of course, design patterns are useful, they don't come out of nowhere. And I think it is essential for developers above a certain level to know them, and recognize them by name. The issue I have with what I called "design pattern fetishism" is that: - Design patterns are typical solutions to typical problems. What some developers don't get is that if you don't have the problem, you don't need the solution. Most design patterns are about adding levels of indirection "the right way", which is sometimes necessary, but indirection has a cost, in performance, in clarity, and in development effort, don't do it if you don't need to. And I agree that it takes experience to know when you need to, that's why I think abusing design patterns is mostly the result of well meaning, well educated, but inexperienced developers. - Naming objects with their design pattern sometimes makes sense, but in other cases, I think it is a bit like Hungarian notation. You often end up with bloated names describing how you implemented a solution rather than what the thing really is. Again, not a clear cut thing, and naming things is hard, but I find some correlation between code full of design pattern names and hard to follow code (even though what the code is doing is not that complex). - Side note: singletons are global variables and shall be treated as such.
- CharlieDigital 4y ago
  I work at a startup with former Amazon engineers in the mid 20's and early 30's. Never seen so many Helper and Util classes with static methods dangling around. Basically no thought at all given to design patterns. Design patterns are of course still a thing and very common in core libraries, but majority of the devs I've worked with over the last year (across 3 startups building full stack) would be lost if I started talking about Visitor and Chain of Responsibility.
  - bluGill 4y ago
    Design patterns make the most sense after a few requirement changes. Startups don't have that yet and think getting to market is more important than staying in the market for long.
    - arinlen 4y ago
      > Design patterns make the most sense after a few requirement changes. No. Design patterns are higher level programming constructs. The need to use and discuss things in terms of higher level constructs does no arise midway through. Or do backend developers only start to talk about controllers and views and dependency injection and singletons after Product changes their mind on something? Absolutely not. > Startups don't have that yet and think getting to market is more important than staying in the market for long. This personal assertion makes no sense at all, and casts doubt on whether you have any idea of what a design pattern is. Your comment reads as a a stream of cliches tied together that have no meaning.
      - bluGill 4y ago
        > Design patterns are higher level programming constructs. The need to use and discuss things in terms of higher level constructs does no arise midway through In part it does. You can hack things up quick without thinking intentionally about higher level constructs and it will all work. When you want to maintain your code for years, then you need to get those constructs in the right place as an intentional act. Sometimes you will put in the right design pattern anyway, but often you won't have them in. Note that this is about the discussion and intentional decision to use patterns. You will of course use design patterns - the difference is getting the right ones in the right place. That takes experience and upfront thinking of a type that startups often do not allow time for. It may well be correct for a startup to not allow time to think about the right patterns overall. It is a decision that will come to haunt them if all goes well, but they got to market sooner. If thing don't go well (a common case), it was less money spent finding that out.
monksy 4y ago
It's not just the resources we have today, in yesteryear we had the MSDN that had an annual subscription and release, we had more books etc. Today, there are promotions and aggressive business fighting of formalization within our field. People who slow down and plan out systems have been weeded out of organizations. People who make things and "ship" quickly are rewarded. This has been the same with quality control in software, and even goes down to bad developers refusing to unit test. Time to being promoted has shortened as well. Now it's not unusual for a dev to be a senior within 2-3 years. Lead in 5. That's just the start of their career. I haven't heard the last time that the title "Jr" was used. > Build and learn along the way It's always been that way but you had a lot more oversight from people that were much more senior.
Fiahil 4y ago
> I think that this is also part of the reason why there has been a shift away from design patterns Citation needed. I see, use and teach design patterns every day, and I work with Data Scientists.
- Rexxar 4y ago
  He needs a citation to say what he thinks ?
q-big 4y ago
> So you'd get a CS degree, read, learn, and apply the knowledge. > That formula has inverted. > Nowadays, you can build and learn along the way. People's opinions by now differ byt a huge amount whether this is a good or bad/dangerous trend.

ShuffleBoard 4y ago

Meh UML was always the Sun Chips of the software world. https://www.theonion.com/sun-chips-abandons-biodegradable-bag-1819560705 https://www.theonion.com/sun-chips-abandons-biodegradable-ba... "Are you kidding me? I crafted my entire freshman year persona around being the 'Sun Chips Asshole.'" PAUL KENEMORE • STUDENT

riedel 4y ago

Posted 1 year ago: https://news.ycombinator.com/item?id=26956298 https://news.ycombinator.com/item?id=26956298 Also interesting is the linked post: https://news.ycombinator.com/item?id=26934577 https://news.ycombinator.com/item?id=26934577

andrewstuart 4y ago

I hated UML because it felt like someone "very important" had issued a commandment from that unless you did software with UML then you were DOING IT WRONG (spoken in a booming voice from the sky). It felt super academic and "Thoughtworks"ish and Javaish and made software development boring instead of dynamic and fun. Glad its gone.

29athrowaway 4y ago
- deleted 4y ago
  [deleted]
- zozbot234 4y ago
  I'm not sure where this notion of UML diagrams as a silver bullet against technical debt is coming from. The whole OOAD development methodology that UML adoption was predicated on is the opposite of serious or rigorous; you can't just translate domain-level "objects" into a design and expect to end up with something sensible, that's not how it works. (In fact, unless some well-defined part of a system really has meaningful invariants that it cares about and should preserve, there's arguably not much of a real reason to even make an "object" out of it.)
  - im_down_w_otp 4y ago
    I tend to agree with this. If UML or something UML-like offers value in terms of understandability at some level of abstraction as a substitute for needing to hold the detailed mental model of the entire explicit implementation in one's head, then using it as something extracted from the implementation to provide a simplified sketch of it makes more sense than using it as an input artifact to creating the implementation.
  - 29athrowaway 4y ago

Thetawaves 4y ago

I considered the explanation was simply that diagrams created in UML are unreadable to lay persons. Excessive use of visual jargon, and changing standards combine to make everybody a lay person, even those versed in a particular version of UML when confronted with a different version.

29athrowaway 4y ago
They are pretty trivial to understand.
- IshKebab 4y ago
  I agree with him. They always had like 5 different types of arrow that had various easily forgettable meanings.
  - Thetawaves 4y ago
    Not just forgettable, but vastly different meanings. And these meanings have changed between versions. You really have to get close to the spec to grok what is actually being conveyed.
- Macha 4y ago
  The devil is in the details - if you have to understand the details like the right arrows for relationship types and visibility modifiers, then it gets much less trivial. And if you're going to omit those details, then do you really need a standard for your adhoc boxes and arrows diagram?
  - 29athrowaway 4y ago
    You can add a legend at the side of the diagram, problem solved.

29athrowaway 4y ago

Sequence diagrams are still widely used. Use-case diagrams should be used more. Class diagrams are good to reveal poor OOP designs.

kieranmaine 4y ago

UML may be dead but I still use sequence diagrams. They're great for visualising complex code and systems, especially if you're new to a system and are trying to gain an understanding the flow of data. I've used mermaid and plant UML and both seem to powerful enough for my use cases, especially when used in conjunction with the preview mode in VS Code.

jmfldn 4y ago
Was messing with mermaid and state diagrams only today. I don't use UML as a whole but some of the diagrams are really useful.
chowells 4y ago
Sequence diagrams are great. Any time there's a multi-stage interaction with multiple independent pieces involved, they're hard to beat for communication. It's not like UML was based on bad ideas. There were just too many cases where the added value was less than the added cost. But when a diagram does add net value it's great to have conventions already.
xh-dude 4y ago
Oh, mermaid looks nice! I hadn’t seen it before. Thanks for mentioning it. If UML tooling had just focused on diagrams, I would not revile UML.
marcosdumay 4y ago
Entity relationship models are good, but people will disagree whether they are UML. Sequence diagrams are useful, but the UML version with a vertical diagram with horizontal lines optimizes for the least necessary use cases; also, the UML one has no space for the participants states. Use cases diagrams are useful, but the UML version just wastes all the space and takes all the useful information out (well, it keeps the actors, could be worse). Class diagrams aren't very useful at all, and when you need them you don't need the formality that is the main point of UML. And finally, the UML designers failed to include any data transformation diagram, because they really did only think in procedural terms.

pipeline_peak 4y ago

UML is too formal for the quick and dirty world of low profile software projects. In whiteboard examples, most people tend to come up with their own “dialect” of UML relational graphs anyway. Not to mention the ease of defining skeleton classes. UML is too trivial to be a standard, feels like a byproduct of the 90s OOP craze. As long as it gets the point across, who cares?

lokedhs 4y ago
You're definitely right about that. Most people think of UML as a notation for relationships between components, and it's useful to have a syntax that people can agree on so it's clear what you're drawing on the whiteboard. But you don't need a 750 page (really) standard creating a formal specification of this syntax. Just in case people don't know just how formal the specification is, here's part of the explanation of event dispatching: As discussed in sub clause 13.2.3, a Behavior execution always has an associated context object (which may be the execution itself). A context object mediates the handling of Event occurrences for all of its associated Behavior executions. When an Event occurrence is recognized by a context object, it may have an immediate effect or it may be saved for later triggered effect. An immediate effect is manifested by direct invocation of a Behavior as determined by the Event, such as the invocation of the method of a BehavioralFeature (see sub clause 13.2.3). A triggered effect is manifested by the storage of the occurrence in the event pool of the object and the later consumption of the occurrence by an ongoing Behavior execution that reaches a Trigger that matches the Event corresponding to the occurrence in the pool

flarg 4y ago

Controversial opinion incoming ... The people who should use UML are too lazy to learn it and instead draw weak abstractions in PowerPoint or C4. Those people are business analysts/requirement engineers/product owners. The true value of UML is that it reduces ambiguity and constrains risk through lightweight prototyping. Wireframes do the same thing. But not one PO can resist writing reams of non descriptive text and drawing impossible data flows. Developers are not the people who should draw UML.

ok_dad 4y ago
Imagine telling a site construction engineer that not only does he have to manage the construction, but he has to develop the blueprints and also become the office manager once the building is done.
- zx8080 4y ago
  > Developers are not the people who should draw UML. > Imagine telling a site construction engineer that not only does he have to manage the construction, but he has to develop the blueprints... Okay.
- somat 4y ago
  The code is the blueprints. The running program is the site. Under this metaphor the construction engineer is the compiler. But yeah I feel the office manager bit, that hits close to home.
  - xboxnolifes 4y ago
    Code may be the blueprint for the program, but UML is still the blueprint for the code.
  - cma 4y ago
    > Under this metaphor the construction engineer is the compiler. What about for interpreted languages?

mhd 4y ago

I do miss the Booch cloud diagrams, they brought a bit of whimsy to OOD.

matt_attack 4y ago

If only it was dead. It's still alive and kicking in military development environments pushed down from above by management.

spamizbad 4y ago

> Ernesto Garbarino says that UML was killed by decreasing standards among programmers: “Agile was the assassin and user stories were her deadly, poisonous arrow heads (pun intended).” I got my start in a shop whose CTO was a big believer in UML. I can tell you unequivocally that software processes from that era, while providing some useful lessons, were a result of the 90s software engineering Zeitgeist, which included these major aspects: 1) Non-technical management was still regularly involved in the management of software engineering and engineers needed to explain “Here’s how we will do X” to laypersons 2) Object Oriented programming was at the peak of its hype cycle, but most of the software development workforce had a superficial understanding of it at best. UML allowed you to explore a problem in an object oriented manner before writing any code and gave more OO-savvy engineers the ability to communicate these concepts to other developers who had no hands-on experience writing object oriented code. 3) The “style” of object oriented programming advocated back then would probably get your hand slapped during any modern code review… even by relatively junior developers. 4) Lots of software development practices we take for granted today were not universal: source control, fast build turn-arounds, automated testing. Likewise, because software was delivered via physical media and your ability to distribute patches was far more challenging the whole process was fundamentally more conservative. So to bring this full circle, what changed since UML’s heyday? 1) Software engineering as an institution matured to the point where almost the entire management chain will typically know not just how to code but actually ship software (seed stage startups are an exception here) 2) Object Oriented programming hype has died down. It turns out it wasn’t the productivity boon we imagined (garbage collection and open source libraries did more for us) 3) Stronger and more robust type systems, Functional programming concepts, and unit testing methodologies are used to mitigate defects 4) Turn-around time to distribute a fix for a production defect is measured in minutes or hours - not weeks or months. 5) Things like CI/CD exist which would’ve made a 90s developers head spin.

katdork 4y ago
other developers who what?
- spamizbad 4y ago

deleted 4y ago

[deleted]

bfung 4y ago

Some UML diagrams are still super useful. The real problem is that the parts of the ecosystem is over engineered and targeted to the wrong audience. For example, Class diagrams, sequence diagrams -> useful for debugging or for implementation, but very bad for product specifications. If the Product person could write class diagrams, they could probably just implement the system themselves. On the other hand, if a programmer was given a class diagram, they'd still need to figure out if the design/diagram was correct to solve the problem they're given. On the other hand, a couple of market-tecture (architecture/systems diagram but made easy to understand to even sales people) was drawn, with some useful descriptions of what the whole system did, people/teams can be assigned to fill out the details, and measure their performance against the constrained problem.

Existenceblinks 4y ago

[Rant] The class in university I hate the most is "Software Engineering" because it doesn't sound like engineering at all. They taught UML, Waterfall, Sequence, ER Diagram, and all useless stuff that I never use within 10 years in software industry.

deleted 4y ago
[deleted]
icedchai 4y ago
Sequence diagrams are very useful for APIs and understanding protocols between systems. ER diagrams are great for presenting a database schema (just don't get too hung up the exact arrow you're using!) When I start a new major project, one of the first things I do is an ERD. You don't need every field (column, attribute...), but the tables (entities, objects, collections, whatever you want to call it...) and their relationships are pretty important.
- tyurok 4y ago
  Yes but it seems the order is taught is important. Without actual industry experience, it never occurred to me it could be useful. After some years working, it's clear it's useful in some capacity but it's easy to overdo it (like require every detail of the system to be in those formats) or misuse it (sequence diagram improperly documenting async flows).
- billfruit 4y ago
  I think statecharts are even more useful than sequence diagrams in documenting behaviour. Statecharts are Turing complete, and succinctly visually encode complex behaviour that is going to take reams of text to describe. Harel et al have done serious, rigourous work in developing statechart.
- Existenceblinks 4y ago
  As I remember ORM / NIAM diagram is more superior that it can turn into 5NF in one go (or two .. can't remember exactly) I find it's easier to think of these data as cartesian product of a bunch of tuple. Even having table in my imagination is confusing!

icedchai 4y ago

I find some aspects of UML, mainly sequence diagrams, useful. Other aspects, like class diagrams, not so much. Plain old boxes-and-line drawings are usually enough. UML was associated with big upfront design, and basically died with "Agile." Why design anything when you can fix it in the next sprint?

ncr100 4y ago

It is useful, and can be overused. I find many software engineers, including myself, have a hard time communicating coherently and specifically the detail of their plans, in my years as a SWE in the fun-startup-space I've enjoyed working. There are ambiguities embedded in many design challenges, and they interfere with UML has been a great way to talk about parameters, data flow, and ownership. I use it for bits and bobs of the conversation, and to help break down problems for distributing the work amongst team members. I don't pre-plan entire projects with UML, though that could be influenced more by business-requirements than the pros and cons of UML.

mark_l_watson 4y ago

Good article, nails a lot of stuff. Before UML, Grady Booch sent me a rough manuscript of his future book Object-Oriented Analysis and Design. I used his diagram style in a C++ book I wrote for McGraw-Hill (I don’t think my book was very good, in retrospect, but the diagrams were nice). A few years later I co-wrote a UML for Java Developers book. Then for years at work I just sparingly used my favorite Sequence Diagrams and a few Class Diagrams - nothing else. In the last 20 years I have just used Sequence Diagrams, and I still like those. Pardon something off-topic, but I would appreciate opinions on this: since we are talking about tidy old fashioned practices vs. agile development, I used to hate full on code reviews, but I enjoyed and thought the lighter weight practice of code walkthroughs or even just having two people read through a code module and fill in a questions form. The author(s) answer the questions, everyone talks a bit, and in the end, reviewing a perhaps 500 line module might take up a total of 3 hours of engineering time - and more people understand more of the system that they are working on if this is done frequently with many combinations of people.

didibus 4y ago

I think the issues with UML and any technique of top/down design is that it doesn't recognize the bidirectional influence of design. The interface influences the implementation and the implementation details influences the interface. Similarly, the whole influences the unit, and the unit influences the whole. You can only design working software if it takes into account both directions, software design has to simultaneously take into account top/down and bottom/up concerns. I think people realized this, and so when you start, it makes more sense to only have a rough top/down draft of the design, since once you implement you'll need to refactor the design anyways from the concerns that appeared from the implementation details. UML therefore became a waste of time, since half of it would change anyways by the time the project shipped.

P5fRxh5kUvp2th 4y ago
I agree with your point, but I don't know that I'd blame UML for that, I'd blame people. It still happens today without UML, it's just moved from flow diagrams to powerpoint and word presentations.
bluGill 4y ago
I worked briefly for a place that generated code from UML. The code itself was ugly C++, but I never looked at it so who cares. Every week the first thing I did was print out the UML on large paper and paste it on my wall. It was nice to see everything on my wall like that, but just one week of one programmer time and what was on the wall was already obsolete in some critical way. One important part of UML is the layout. Every week I.made a minor tweak to how the boxes were on the page so things looked nice. Every few months a larger change to layout. Since then I've been to a lot of places where people ask for UML, but since there is no way to synchronize the code and UML the UML is left to rot. We could keep it up to date and i'd love it, but that means one full time graphical person for every two developers. I don't think UML is worth it unless it is the code.

mrleinad 4y ago

How do you explain an architecture to other developers?

pamelafox 4y ago

I still find it helpful to use UML diagrams in a classroom setting when describing a project codebase at a high level. For example, this slide diagrams some classes used in a Scheme interpreter: https://inst.eecs.berkeley.edu/~cs61a/sp22/assets/slides/30-Modularity.html#/24 https://inst.eecs.berkeley.edu/~cs61a/sp22/assets/slides/30-... (Generated with PynSource) I also find such diagrams useful in an engineering setting when explaining a codebase or design decision to teammates.

_8j50 4y ago

Would a short description of UML at top hurt. Here I am trying to figure out how thid related to user mode linux. I stopped mid way and had to read comments. Either way, didn't know UML died, visio still supports it right?

dzdt 4y ago
Same. User Mode Linux was my guess; the first paragragh of the article was enought to tell me that was wrong but gave no hint of what the acronym might mean, not even broadly. I had to google : it is actually about Unified Modeling Language diagrams of object classes and their relationships. I guess nobody who uses UML diagrams ever thinks of UML as an acronym?

isthisthingon99 4y ago

UML is not dead, I use UML diagramming all the time. As with anything, you want to be judicious in your use of it. Edit: shoutout to https://plantuml.com/ https://plantuml.com/ for making me the coolest kid on any new team.

ttfkam 4y ago
Seconded! You can have my PlantUML when you pry it from my cold, dead hands. Once I was shown diagram source you can diff between revisions, I was sold.

buescher 4y ago

UML statecharts are great, but I’ve not yet used them end-to-end and I’m not mourning the passing of UML-driven OO methodologies.

FpUser 4y ago

I use ER diagrams, Sequence diagrams, State machines, Use case diagrams etc during planning design stages and find it really helpful to capture business processes / requirements and turn those down to a rough design. Except trivial cases (of which I admit we have plenty) thinking before piling up code has great value. What did die is insane approach preached by fanatics in Rational. Now we have the same situation with Agile / SCRUM. I hope this abomination (the way it is being forced down everyone's throat) suffer the same fate. The other related subjects are / were - everything has to be, OOP, OOP sucks, let everything be pure functions and other crap like this. Luckily I've avoided all the propaganda and sticking to "the only true religion" never mind that new new one would come out every other year

pxtail 4y ago

When UML concept was introduced to me at university I was astonished by it and thought that it's really brilliant - I perceived it as parallel concept to construction and architectural blueprints. I noticed how it helped to plan software development, spot hidden issues, missing functionality, revisit functional requirements with general design of software before even trying to write any code - it also was obvious for me that it is a tool for people with a lot of experience under the belt, aware of best practices, possibilities, common pitfalls etc. I really liked whole concept, I'm sad that it isn't common practice now - probably just too expensive to do instead of just bashing keyboard buttons and stitching together some libraries However I think that it will return in some form at some point - software as a craft is incredibly young compared to for example construction AND "everything old is new again" is incredibly popular in this field of work ;)

cartoonfoxes 4y ago

Despite being mostly a subset of UML, SysML is a more cohesive and useful design and modeling tool. Unlike UML, I've actually used SysML on real embedded systems projects and like it. It lends itself well to model refinement, wheras UML encourages Big Design Up Front. I'm not sold on the idea of capturing an entire design within SysML, but using it instead as a diagram format with defined semantics for situations where group discussion or communication with third-parties calls for some graphical aids. I think as long as you're not trying to make executable models, do code-generation, or replace a formal specification tool like TLA+, there is real value in it. The documentation and training ecosystem around it is pretty decent, as well. The SysML books I've read have all been way more pragmatic and grounded in actual engineering practice of building systems from many components sourced elsewhere, for which design capture is necessarily incomplete.

kejaed 4y ago
What tool did you end up using for SysML?
- cartoonfoxes 4y ago
  Currently, I'm not currently working in a dedicated modeling tool at all - just draw.io. We started with Enterprise Architect from SparxSystems - it's a bit janky and covers a lot stuff beyond SysML, but it works fine. Cameo Systems Modeler is good too - it omits the non-SysML garbage that the other platforms include, and has the best Model-to-Html rendering I have seen, but was double the cost of EA so did not use it for work. The open source tools, Modelio etc. were all a broken waste of time. For my use, there is a sweet-spot for "models" spanning only a handful of diagrams (5-10) where any drawing software with SysML templates will do. The dedicated modeling tools like EA or Cameo become relevant once you're trying to keep model elements consistent across a large number of diagrams. Draw.io is free so the whole team can use it, and the the lack of model representation keeps diagram count low and not over-specified. Cool products, btw.

bane 4y ago

UML came up a few times during my CS program years ago. I found it kind of infuriating at the time since it just seemed to be an idea vacuum cleaner that sucked up so many different diagramming ideas into one place and stuck somebody else's name on it -- plagiarism at an enterprise level. I've grown to somewhat respect it to a point as a formal way of documenting a system, but goodness no, would I never ever design a system with such cruel intent.

neilv 4y ago

As someone who learned and used a lot of the methodologies before UML, and developed CASE tools for some of it, looking at discussions of UML are painful, for two reasons: 1. It seems that almost everyone commenting has seen only bad uses of UML. Even before UML, there've always been people who used modeling tools without understanding them, there've always during OO era been people who really only wanted to see a class inheritance hierarchy, and knowing when to use the models and when to code or do other things is an art like much of the rest of software development. We've got a lot of people writing one-star Amazon Customer Reviews for a screwdriver, who've never seen a screwdriver used properly, and only know hammering. 2. When I try to use particular models and views of UML myself, the documentation and tooling I find in the time available borders on unusable, and I end up improvising what I need. Given that I know a lot of the influencing methodologies, and I've even developed tools myself, if this now looks like crazy enterprise sales&consulting cash cow nonsense to me, then I can't be surprised if other effective software engineers are turned off by what they see. But that's sad, because the value is there, just obfuscated.

thematrixturtle 4y ago
This argument sounds very much like "the problem is not communism, all those countries just weren't doing real communism". And I'm not even being quite as flippant as it sounds about communism here. Communist economic planning relies on accurate central planning, which we've learned the hard way is essentially impossible at the scale of a nation state. In the same way, UML assumes you can meaningfully model a complex computer program in advance, which tends to fall flat back in reality where requirements are poorly understood and evolve continuously.
- cyanydeez 4y ago
  I think the most coherent argument for failure is the limited automated feedback between real code and the uml
- neilv 4y ago
  I don't know enough about communism to make analogies there. I do know that there are successful uses of screwdrivers, and that a screwdriver makes an ineffective and dangerous hammer.

zmmmmm 4y ago

I think the biggest one is the "rot" problem. Software iterations have gotten faster (in general, not just due to agile) and it just seems pointless documenting things separately with diagrams when so often they have a short lifetime of accuracy. Then, not having a good text representation means it does not play nicely with version control which compounds it all (how can you get the right version of the diagram for the specific software). It did not help at all that the UML tools were typically expensive so only the ivory tower architects would have them so most of the team couldn't actually edit the UML. I do remember a phase where I used TogetherJ extensively as a full round-trip UML tool. It very nearly worked to the point where I could edit things on the UML diagram and the dive into edit the individual classes and methods in code. PlantUML has done a lot to help with this for our team. The slowly evolving convention of embedding PlantUML/Mermaid into Markdown and / or code comments is starting to enable a more maintainable / agile way of doing this. In particular have found Znai recently as a nice tool that brings all of this together along with code extraction to make nice "user manuals" comprised of documentation in markdown format and code comments.

bitwize 4y ago

Ah, UML. You were positioned to replace programming altogether in the early 2000s. We were told there would be no need for programmers when you can just turn a crank and get Java generated from UML diagrams. And CASE! The low/no code of the 80s! How the mighty have fallen. Important things to bear in mind when considering this era's silver bullets...

qiller 4y ago

We had a ton of formal modeling classes back in college, but about the only two concepts that stuck with me and still being used when we need to document something are the UML sequence diagrams and a somewhat less known IDEF0 activity diagrams - https://en.m.wikipedia.org/wiki/IDEF0 https://en.m.wikipedia.org/wiki/IDEF0

Rochus 4y ago

> they bought Jacobson’s consulting company and phased out OOSE The method and tool by Jacobson and colleagues was actually called Objectory, not OOSE (the latter is the name of a german consulting company which pubished their own method called OOSE more than two decades ago). Objectory as a method and tool was excellent, especially for analysis and design. Rose (the Rational tool) might have looked prettier than the Objectory tool but couldn't do much more than diagram drawing. Unfortunately the Objectory tool vanished after they bought it. UML and RUP have suffered the same fate as all methods. After a certain time in evolution, people have forgotten the original intentions and concepts, watered them down beyond recognition or diverted them from their intended purpose, and instead only formalistic but useless rites are practiced, which is commonly referred to as cargo cult. The same fate will happen to Agile (or it has already happened).

jdougan 4y ago
Object-Oriented Software Engineering is the title of Jacobson's 1992 book describing a reduced tool-less version of Objectory that was referred to as OOSE. ISBN 0-201-54435-0 To this day I still use OOSE notation when sketching a design, I alwas thought UML was a step down.
- Rochus 4y ago
  You're right, the book does not present Objectory, just the fundamental ideas. But RUP was the continuation of the "Rational Objectory Process", which was Objectory gradually using UML instead of the original diagrams. The fellow referred to Jacobson's consulting company and RUP and UML, not Jacobson's text book. I still have the original Objectory documentation, and even asked Jacobson many years ago whether they could open source the Objectory tool, but unfortunately that didn't happen yet (at least not to my knowledge).

mbfg 4y ago

I think IDEs killed UML. You can look at a model and understand a system, then try to translate that to a code base, and try not to lose anything in the translation. Or you can just use an IDE and find all these things that UML tells you directly on the code base, and do no translations.

packetlost 4y ago

If you can't break down your systems model into a subset of inputs, outputs, and domains (which can be broken down even further to whatever degree of complexity necessary), someone probably doesn't fully understand their system very well. Yeah, UML is chunky, but the ability to identify the high-level goals of a system allows you be be focused on how those systems should behave and the rest is just meeting that spec reliably (or within whatever margin of error is determined to be appropriate). If things are truly inter-dependent, the ability to identify risk points as a high, abstracted level is invaluable.

globalreset 4y ago

It died because it's stupid and useless.

osigurdson 4y ago

The industry has always wanted to have a small number of smart people creating designs which can be handed down to a large number of dumber people to implement. We can't seem to accept that it doesn't work that way. That being said, UML isn't horrible, it's just fundamentally unimportant.

nitwit005 4y ago

One thing that changed was just scale. Many visual representations of information are great, up until a certain complexity, and then people can't tell what they're looking at. A coworker demoed some Rational product to us back in the day. It was very impressive, creating class diagrams from existing code. It was also an incomprehensible mess of nodes and edges.

dqpb 4y ago

UML conflated system modeling with diagramming and focused too much on the diagramming.

KronisLV 4y ago

> I wouldn’t expect two teams in different companies, one in California and the other in New York, to use similar notations unless someone was deliberately keeping them in sync. I feel like you need a reference implementation for almost any spec out there for it to remain consistent, like a tool that everyone might use for working with UML or whatever. For example, have a look at BPMN, which has https://bpmn.io/ https://bpmn.io/ without which it would be another spec that many wouldn't care about. Of course, the tools actually need to be good, because I've seen too many bad Eclipse based pieces of software, like for 4EM modeling or other approaches that never really took off in the real world, outside of niche contexts. It might be a case of model driven development feeling pretty useless, unless it actually helps you develop the solution with minimal friction. A good example of this are ER diagrams in MySQL Workbench! For example, consider the following, what I've sometimes done: - open MySQL Workbench - reverse engineer an existing DB, get an ER model - alter the model as necessary (add tables, change columns etc.) - use the forward engineering/synchronization tools to get DDL that could be applied to DB - execute or alter as necessary beforehand Contrast this to the workflow that a colleague of mine had: - open draw.io - open a manually drawn ER diagram of the DB from local/shared disk - compare against DB schema manually, possibly fix parts that have changed in the DB since last diagram update - alter the model as necessary, using regular drawing elements and text (with lot of it being more like working in Paint) - once happy with this "documentation" and it looks good, manually write all of the SQL that's needed for migrations - execute the SQL I think the best kind of documentation and models is the one that doesn't lie to you (can be updated automatically) and tools that integrate with what your infrastructure/application/schema actually is supposed to be, rather than some out of sync model. Otherwise you end up with documentation that is wrong or that nobody cares about. If you want something like UML or any other modeling approach to be popular, I'd argue that you'd need something like the following: java2uml --in-package src/java/main/dev.kronis/sales_app_2022/products --out-model products.uml "MadeUpSoft UML Studio" > File > Open > products.uml ... do your changes "MadeUpSoft UML Studio" > File > Save uml2java --in-model products.uml --out-package src/java/main/dev.kronis/sales_app_2022/products Until we have model driven development that goes both ways (forward and backward engineering), the use cases for it will be severely limited.

ttfkam 4y ago

iLoveOncall 4y ago

People that think UML is dead are people that work in companies with terrible engineering practices. I haven't been in a single decent team that didn't use UML to some extent for designing components. I just don't see how you could do a design review with your team without using UML.

specialist 4y ago

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

scioto 4y ago

Peer pressure led me to purchase The Unified Software Development Process, The Unified Modeling Language User Guide, and Fundamentals of Object Oriented Design in UML, and while I tried to read them and understand what they were trying to accomplish, I realized that putting ideas and concepts and flows into formal diagrams with rules to argue with others really wasn't getting me or my group anywhere. So we went back to whiteboarding and mostly doing top-down design (using decomposition to get down to actual data flow), and we got our products out the door. In the meantime those books took up space on my shelf and ended up being more for impressing people who walked into my cubicle (remember cubicles?). Now in my home office two of the three are makeshift monitor stands. I'm finally going to try to dispose of them somehow without harming the environment. I think they're recyclable.

mejutoco 4y ago

IMO UML died because it was too coupled to OOP (maps directly to objects/classes) and it is (like most visual languages) a more verbose version of the textual version (probably Java classes/interfaces). Of course it is still useful to communicate an idea, but so is a diagram or an MVP (maybe with some formal guarantees from the type system or a TLA-like "proof")

makeitrain 4y ago

Just take a picture of the whiteboard with your phone and upload to jira.

dwaite 4y ago

We did quite well back in the day with the "UML as blueprints" approach, and I personally felt that for new complex systems that mapping between various diagrams and the use cases helped greatly in clarifying a larger OO system before we started writing code. I felt creating diagrams and getting consensus at the start of iterations made us significantly more productive and produced better results. But most active tooling and education for UML was always CASE-oriented, which was way too heavyweight for such a small org. I would use more "UML for sketch" tooling - like OmniGraffle with good (internal) stencils - which allowed for iterative improvement to the diagrams. I actually switched from Linux to Mac for OmniGraffle. Invariably the UML tooling of the day was too cumbersome, because it was geared toward making more formal models from the outset. It is the UML sketching which I have kept throughout my career, and lamented that as CASE died, there hasn't been anything else to supply baseline education nor has there been any evolution (or simplification, or unification.) I suspect creating such things just isn't that attractive without the CASE money being there.