[HN Gopher] Why UML "Really" Died
       ___________________________________________________________________
        
       Why UML "Really" Died
        
       Author : onemoresoop
       Score  : 17 points
       Date   : 2022-09-09 20:11 UTC (2 hours ago)
        
 (HTM) web link (buttondown.email)
 (TXT) w3m dump (buttondown.email)
        
       | Thetawaves wrote:
       | 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 wrote:
         | They are pretty trivial to understand.
        
       | CharlieDigital wrote:
       | > 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 wrote:
         | > _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.
        
         | monksy wrote:
         | 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 wrote:
         | > 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.
        
       | ShuffleBoard wrote:
       | Meh UML was always the Sun Chips of the software world.
       | 
       | 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
        
       | 29athrowaway wrote:
       | Sequence diagrams are still widely used.
       | 
       | Use-case diagrams should be used more.
       | 
       | Class diagrams are good to reveal poor OOP designs.
        
       | kieranmaine wrote:
       | 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 wrote:
         | 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 wrote:
         | 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.
        
       | riedel wrote:
       | Posted 1 year ago:
       | 
       | https://news.ycombinator.com/item?id=26956298
       | 
       | Also interesting is the linked post:
       | 
       | https://news.ycombinator.com/item?id=26934577
        
       | pipeline_peak wrote:
       | 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?
        
       | flarg wrote:
       | 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.
        
       | andrewstuart wrote:
       | 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 wrote:
         | "I don't want to think, I want to pump tech debt and be the
         | managers' favorite tech debt fairy, waahhh. Why do you want to
         | turn software engineering into a serious occupation? I want to
         | lower entry barriers and depress my own wage, waaaah."
        
           | zozbot234 wrote:
           | 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 wrote:
             | 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 wrote:
             | If you are a tech debt fairy, your main source of comfort
             | is lack of visibility.
             | 
             | No audits, low visibility = perfect for the velocity
             | contest champs.
             | 
             | The more visibility on how deliberately unmaintainable and
             | duct taped your shit is, the worst for you.
             | 
             | Your bet is that by the time someone audits your shit you
             | are already a manager that doesn't have to code anymore.
        
           | andrewstuart wrote:
           | I don't even understand what this means.
        
       ___________________________________________________________________
       (page generated 2022-09-09 23:00 UTC)