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

221–230 of 427 posts

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

#221

Post by devin »

hejcloud wrote: post #204
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…

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 also interested in the german software engineering culture. And also, heavy plus to this being a social problem more than a "engineers just need more time" problem. I tried to articulate this in another comment of mine but mostly beat around the bush. This is more directly what I was attempting to say.

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

#222

Post by ivan_gammel »

marcosdumay wrote: post #69
ivan_gammel wrote: post #34

Earlier quoted context omitted.

Every software engineering team in my 20+ years career actually used 2-5 types of UML diagrams: classes, sequences, deployment, activity, state. I think it mostly depends on maturity of the team and engineering culture, whether UML is used or not. There’s certainly some value in it.

I don't think I have ever seen anybody actually getting value from a class diagram. I have seen many people creating them, but they are always useless. I also don't think the UML variant of state machines and workflow are any popular. But well, there is probably somewhere where people use them. Also, those lists usually ignore entity-relationship diagrams, where UML just adopted the popular format (without even minor…

> I have seen many people creating them, but they are always useless.

Not every artifact is worth keeping, instead the value can come from the process of creation as a way to structure your thoughts or to explain or brainstorm possible solution. The value of class diagrams for those people is in the moment and it’s ok to throw them away later if they become useless.

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

#223

Post by mytailorisrich »

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…

The problem is that the expection was to document the software design in excruciating details (e.g. class diagrams with all fields and methods, etc.) before any coding. To the extreme you were meant to all the coding in your head and a Word document before doing it again in your IDE.

This wastes a huge amount of time and usually the documents become obsolete as soon as you try to actually run some code.

This is the very issue the Agile manifesto identifies and proposes a solution to when it says "working software over comprehensive documentation". 'Comprehensive' is a key word as they don't mean NO documentation but effectively just what's needed to plan and help people understand the code.

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

#224

Post by lmm »

icedchai wrote: post #210
lmm wrote: post #181

Earlier quoted context omitted.

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.

My experience is that shipping stuff that doesn't get used by any actual end users is more often caused by thinking ahead too much than by thinking ahead too little.

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

#225

Post by beyonddream »

jt2190 wrote: post #174
beyonddream wrote: post #167

Earlier quoted context omitted.

I am curious to know what are these “formalized architectural decision making methodologies” ? Any books that u know of that cover these topics ?

“Rational Unified Process” https://en.m.wikipedia.org/wiki/Rational_unified_process

Oh this! I suffered learning this during college ;)

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

#226

Post by qwertywert_ »

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…

Overdesign is one of the worst things to do. Trying to make something fit perfectly into some obscure pattern with horrible class hierarchies. Look at the linux kernel sources, it does not look "beautiful" to some architects but the actual ideas and patterns are simple, anyone can jump into it if they know C.

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

#227

Post by taeric »

ivan_gammel wrote: post #219
taeric wrote: post #46

Earlier quoted context omitted.

With the odd caveat that you probably use sketches of these diagrams? As soon as you are trying to cram in all of the extra details stuff like class diagrams can do, you are probably wasting time.

I do not understand your question. If I do not deviate from convention but omit unimportant details, is it a sketch for you? If you have a project document template from PMBoK, do you feel obliged to fill all the sections or you document only information relevant to your project? With UML it’s the same: it offers a lot, but you do not have to use everything to produce a conforming diagram.

It it a sketch if you don't include every detail that UML was specifically designed to convey? Yeah? Noting that a sketch is not a derogatory phrase here.

Note that, for many of these diagrams, they existed before UML. It was an attempt to formalize them. In classes, they are often used as code generation tools in an attempt to keep a 1:1 between document and code. Laudable, but I have yet to see that work out well.

To your point, I think, the same ultimately goes for document templates. Way too many are used prescriptively as a way to make a successful project. Much to the chagrin of the document writer when the project fails. Often miserably. To the point that I'm convinced most accurate project documents are after the fact. Certainly not waterfall to the project that they are describing.

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

#228

Post by Rochus »

mhandley wrote: post #185

Sequence diagrams are very useful, but UML just adopted a representation that already existed decades before. For example, the original 1981 TCP specification in RFC 793 [0] has ASCII sequence diagrams (see figures 7 to 14, etc). I don't know if they predate that - less from that era is online - but I wouldn't be surprised. [0] https://www.rfc-editor.org/rfc/rfc793 Edit: there are a form of sequence diagram in an ear…

Sequence and activity diagrams were already present in Jacobsons original method, which again is based on the "Ericsson Approach" (originating in 1967), long before UML; they were called interaction diagram and state transition graph.

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

#229

Post by rerdavies »

But it is a great tragedy that we don't have some standardized vocabulary for sketching software architecture (ownership vs. flow of control between components, for example). Something beyond just boxes and arrows. To use for sketching and absolutely nothing else, of course.

I do still use sort-of-UML diagrams for sketching architecture at the 10,000ft level, after the software has been written as, as a kindness to those who follow in the piece of documentation that hovers somewhere around how to build the project. I'm not sure they are truly useful anywhere else. But they are useful.

Note the last fading vestiges of my Rational UML Training Course (unspeakable waste of time and money) in this diagram from the architecture page of one of my personal projects:

   https://rerdavies.github.io/pipedal/Architecture.html
I think they're interesting in that they borrow useful vocabulary from UML, but they also a need to invent vocabulary that (probably) isn't in UML. Also that it's probably not valid UML, but I don't care. And that the basic information it provides is which of seven files/classes you would start in, when trying to fix a bug, before you started crawling through the remaining 174 files and ~250-ish classes.

And most interesting of all: that there is no standardized notation conventions to deal with such diagrams that I would expect anyone to understand. I don't think it's reasonable to expect anyone who started programming in the last 20 years to even know what UML is.

My vision of Rational and Grady Booch, while living through that period...

- Grady Booch, an unassuming genius, who had a modest but really very good idea.

- Rational: An insane pack of underfed marketing guys, probably run by a relative of Elizabeth Holmes, who had absolutely zero understanding of the underlying problems UML was designed to address. Ever promising, never delivering.

Maybe it's time to revisit Grady Booch's modest but really very good idea, and consider whether it can be rescued from the horror that UML became.

Post reply on HN