Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sequence diagrams, the only good thing UML brought to software development

mermaidchart.com

Post reply on HN
Print view View original

191–200 of 427 posts

Re: Sequence diagrams, the only good thing UML brought to software development

#191

Post by doctor_eval »

fmajid wrote: post #188
mkozlows wrote: post #169

Earlier quoted context omitted.

Yeah, hard disagree on all that. As someone who lived through that era professionally, and who has had an "architect" title in the past, I was actually resistant to ever stepping into that role, because I had so many bad experience with the Formal Architecture Methodology crew, who would produce the most absurd and out-of-touch designs. There's a reason that "architecture astronaut" is a term from that era. Lots of p…

Seconded. I once went to an IBM seminar with Grady Booch and seldom have I heard such an inane string of platitudes. Architecture Astronauts are the worst, and if there is one thing Agile can legitimately claim for, it's getting us rid of that plague.

I agree with you both except that architects are alive and well. I worked with an ex IBM architect a couple of years ago. Lovely guy but for someone designing software systems, I found it remarkable that he didn’t know how to write code.

Re: Sequence diagrams, the only good thing UML brought to software development

#192

Post by esfandia »

Dig1t wrote: post #8

Spot on, I agree that sequence diagrams are super useful, I see them used all the time in FAANG. I do really wonder why UML is still taught in universities, as the article states, it's pretty useless. I took a masters Software Engineering course at Georgia Tech two years ago and a big part of the class was learning UML. That time was mostly wasted as I've never used any of it and never met anyone who has used it. It…

It's certainly given too much importance in the curriculum, but the idea of having a common language (with standard semantics) for sharing design decisions is valuable.

I'd argue the issue is that because UML is not seen as valuable, everyone improvises their own dialect when drawing stuff, and so since nobody trusts people following correct diagram semantics (e.g., meaning of different arrow shapes), nobody trusts the resulting diagrams either, further reinforcing the notion that it's useless.

Re: Sequence diagrams, the only good thing UML brought to software development

#193

Post by cubefox »

IshKebab wrote: post #97
cubefox wrote: post #80

Earlier quoted context omitted.

People who say "UML is useless" basically say "diagrams are useless". Which obviously isn't true. The alternative to UML is everyone inventing their own "diagram language" when they want to visualize something. Moreover, I think comparing different UML diagrams can also be enlightening for university students. E.g. state machine digrams look quite similar to activity diagrams, but the former emphasize states and the…

> everyone inventing their own "diagram language" This is clearly better than UML. UML is full of shorthands that nobody remembers. That's worse than people making labelled custom diagrams. Here's an example: https://buck2.build/docs/concepts/concept_map/ Imagine how much worse that would be with UML arrows.

That concept map example is only a loose association of ideas, where the nodes aren't of the same type (e.g. event, state, class etc), or sorted into types, and apparently included quite arbitrarily. Mind maps are similarly loose. UML is for when you want more precise diagrams about a fixed subject matter.

I agree on the "shorthands", like empty/filled arrows, that people may not know. But there isn't much alternative to such shorthands other than leaving them out completely, which wouldn't be an advantage. In diagrams some information is either conveyed succinctly or not at all. The "alternative" is a block of text instead of a diagram.

Re: Sequence diagrams, the only good thing UML brought to software development

#194

Post by imiric »

johnyzee wrote: post #160
imiric wrote: post #31

I also find sequence diagrams to be the most useful, but disagree that the rest of UML is useless. Class, component, package, activity and state machine diagrams are all useful ways to model the structure and behavior of a system visually. The only reason the other diagram types fell out of favor is because of the development methodology change starting in the early 2000s. The industry started rejecting Waterfall, ea…

> Most developers IME actively reject these diagrams because they are quickly outdated, or require constant changes to keep up to date Plans are useless, but planning is indispensable. The act of diagramming things up front is useful to get you thinking about the problem space and come up with the outline of a solution. After that, keeping the initial design documents up-to-date is optional, and often might not be ne…

I think about it the other way around, actually.

During the prototyping phase diagrams do help, but they're usually sketches written on paper or whiteboard. You don't want to waste time with tools and strict specifications to design perfect diagrams, mostly because the design will change frequently, and you don't want your tools getting in the way.

Later on, once the design has settled down and maybe once development has started, those initial diagrams are mostly worthless, but you _do_ want neat and professionally done design documents that describe the system. This allows you to share them with coworkers, and quickly onboard other developers to the project. Hopefully by then the design won't change frequently, which would make updating these a chore.

Re: Sequence diagrams, the only good thing UML brought to software development

#195

Post by jrochkind1 »

dahwolf wrote: post #158

In some ways, software development practices have degraded since that era. It largely has to do with the need for speed which comes at the expense of careful consideration, quality, integrity and the formal standards that support it. In fact, I believe it pretty much killed the profession of software architect. Many teams had it as a dedicated role, and this indeed would be a person documenting/designing systems usin…

> And they'd know the classics, like memorizing all design patterns.

That sentence is bringing back ptsd-like flashbacks.

I remember distinctly how much everyone thought that approach you describe was broken when it was the trendy thing.

I'm not sure how universal it ever was, but it was at one point a trendy thing that everyone thought they should be doing... and that so many people subject to found disastrous. [The phrase "architecture astronaut" was a common epithet, and not a friendly one]

That above paragraph [without the brackets], ironically, could certainly be said of "agile" more recently too. I don't know how universal it ever was, but it was at one point a trendy thing that everyone thought they should be doing... and that so many people subject to found disastrous.

But yeah, I'm pretty convinced going back to appointing some almighty deity architecture astronaut who isn't responsible for or involved in any implementation (let alone operations!), who hands down plans from on high after "memorizing all design patterns" and drafting some diagrams, never sullied by "contact with the enemy"... no thank you, but thank you.

----

Instead of just complaining about that though, what I'll say in addition is -- I think the real problem is that engineers aren't given the time to carefully consider top-level designs. it's a basic business/resource issue -- until engineers have more breathing room to talk to each other and research and consider and come to decisions in an unhurried way, the top-level design stuff will remain chaotic. It's not an issue of appointing an ivory tower "architect", or something solved by it.

Although sure, there should be senior and even "staff" or "principal" people with more authority/responsibility for higher-level designs.

Everyone should be responsible for design at the level they are working. Everyone needs enough time to feel like they are doing it well, instead of running on a sweatshop code production treadmill.

Re: Sequence diagrams, the only good thing UML brought to software development

#198

Post by yafbum »

dahwolf wrote: post #158

In some ways, software development practices have degraded since that era. It largely has to do with the need for speed which comes at the expense of careful consideration, quality, integrity and the formal standards that support it. In fact, I believe it pretty much killed the profession of software architect. Many teams had it as a dedicated role, and this indeed would be a person documenting/designing systems usin…

We haven't told ourselves that shipping garbage in short cycles is the only way to do things. The market has pretty much determined that companies that over invest in formal software design activities lose out competitively in the long run, and the survivors are the ones with the right balance. You're welcome to prove the market wrong.

Re: Sequence diagrams, the only good thing UML brought to software development

#199

Post by maximinus_thrax »

dahwolf wrote: post #158

In some ways, software development practices have degraded since that era. It largely has to do with the need for speed which comes at the expense of careful consideration, quality, integrity and the formal standards that support it. In fact, I believe it pretty much killed the profession of software architect. Many teams had it as a dedicated role, and this indeed would be a person documenting/designing systems usin…

> Everybody is half-assing design or skipping it entirely. Solutions are reinvented and tech choices made on a whim by the loudest person whom won't see the consequences of it anyway. Because we've told ourselves that shipping garbage in short cycles is the one and only way to do things.

I agree. I don't personally fetishize the old slow processes nor ivory tower architectures, but I think there's a healthy spectrum between that and the complete 'software fuckery' (https://web.archive.org/web/20160308032127/https://medium.co...)

Re: Sequence diagrams, the only good thing UML brought to software development

#200

Post by CyrsBel »

UML is really powerful but definitely could be more simplified to just be basic charts. The problem is that sometimes you need to see the full complexity to be able to start simplifying systems. The real issue involving a decades-old process that gets in the way isn't actually UML though it appears at first to fit that description. It's actually scrum. Scrum-based methodologies on how to deliver value to the business. Scrum eventually forces engineers to make trade-offs like how thorough their UML and regular flowcharts can be which is not a scalable way to build quality products. The charts should be precisely as complex as is needed to accomplish the business objective and ensure that the business is always able to be in the best starting position possible to continue working on a piece of code or a system with just that documentation as the starting point. Sometimes this does mean that a demo may be just a bunch of UML or simpler flowcharts that have more breadth instead of user functionality.

UML makes sure that product functionality knowledge can be more easily restored or understood from an engineering mindset. It encodes a lot of information into the format and simpler options exist too. But I have to say once again that you almost got it right as to which decades-old development methodology is pretty deprecated despite still being in fashion - it's not at the diagramming layer, it's at the project management layer.

Post reply on HN