Live data from Hacker News

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

mermaidchart.com

201–210 of 427 posts

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

#201
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…

UML was (and still is) really useful when embarking on a greenfield design. Most people I've worked with know some basic UML notation, so when it comes to whiteboarding and refining the design, it makes sense to go with that.

In terms of artifacts for future maintainers? Maybe not as helpful. As previous posters have mentioned, the diagrams go stale very quickly if the engineering department isn't disciplined about keeping documentation up to date. But this is true for any documentation.

Some diagrams (class and activity, in particular) are less valuable as time passes. I can get the idea of the class structure by just looking at the code itself. The class diagram just ends up being a stale representation of the code.

It is unfortunate that UML has developed a reputation as being overly complex. Now I see more ad-hoc diagrams being created, with whatever notation/symbols make sense to author, rather than using a common diagram system that can be read by many.

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

#203
post #76

Thinking "the only good thing" is understandable, since there's a lot of noise, but that talk discourages people from learning a lot of good stuff that's buried. Before UML, there were many methodologies. UML was started by a unified team of some of the most noted OO methodologists. There was a lot of good thinking, but one of the adoption problems we had before UML (as tools developers and methodologists) was that m…

Definitely, bad diagrams (as opposed to bad diagram notation) give UML a bad name. Your example of the misuse of state diagrams as a glorified flowchart is something I see very often.

Undergraduate students probably don't have the experience and design maturity to fully appreciate when and how to use most UML diagrams. I think you need to get stuck at design problems a few times before you can appreciate the need to capture ideas using the right diagram, and then you might be ready to adopt some standard so you can share your design decisions with others in a way that correctly captures and conveys just the right amount of detail.

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

#204

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…

German speaking. You can take German IT to get an idea what would have happened to SWE if you'd have kept those bureaucratic methods from the 2000s as the backbone of all SWE endeavors: a horrible, expensive, non-working mess with barely any progress.

I think what many people, esp. from outside the SWE world, don't get: Software engineering is a deeply social kind of work. There are dozens of solutions for the given problems, you have to agree on one that works for all peers. That's the job. Optimizing it for drawing funny diagrams is not an issue if not for communication.

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

#206

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…

German speaking. You can take German IT to get an idea what would have happened to SWE if you'd have kept those bureaucratic methods from the 2000s as the backbone of all SWE endeavors: a horrible, expensive, non-working mess with barely any progress. I think what many people, esp. from outside the SWE world, don't get: Software engineering is a deeply social kind of work. There are dozens of solutions for the given…

I'm not familiar with how IT works in Germany. What's different about it? Got any stories?

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

#207

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…

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…

Could we bring back the UI people from that era though? Trying to standardize good software is insane but having a consistent UI with standard elements for all programs that's usable with both mouse and keyboard was kind of nice.

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

#209

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…

To be fair to the design patterns people, a lot of them got baked into pieces of infrastructure like web servers and frameworks, while others are part of frequently included libraries.

If I went through and inspected any Node, Rails, Django, etc app I would find many Gang of Four design patterns, but very few of them would be in the project-specific code. They got implemented well, and now programmers can build new things that would have taken too long to do before.

And that was the intent of the Gang of Four book, not to teach you patterns you should copy mindlessly, but to give examples of how to identify and extract useful patterns from the software you've already written and describe them to others. Since that is a lot more difficult than memorization, very few took up that work.

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

#210
post #181

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 stopped doing that stuff because it was useless. We eliminated those practices and that profession because it was actively harmful to making good software. All those decision making methodologies consistently lead to worse technology choices than one dude actually trying to write some code with the thing for half an hour.

UML is mostly useless, but thinking ahead, even a bit, has value. I've seen stuff shipped in a sprint that was not used by any actual end users, only to be "redone" in the next sprint.
Post reply on HN