Earlier quoted context omitted.
> 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 t…
Sequence diagrams, the only good thing UML brought to software development
231–240 of 427 posts
Re: Sequence diagrams, the only good thing UML brought to software development
#232Spot 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…
Why the university teaches outdated useless stuff? My guesses: - For the university, it fills out offerings and takes up credit hours, keeps the tuition dollars flowing - For the teacher, it's something they already know how to teach, so it doesn't require nearly as much effort to teach as something more useful but maybe less familiar - Universities are trusted with the decisions of what to teach and don't face much…
Without those various perspectives, you end up with students learning all kinds of goofy things just because no one said, nah, they’re probably not going to need that.
Re: Sequence diagrams, the only good thing UML brought to software development
#233In 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…
Having lived through both, modern development practice is superior in practically every way, most especially with respect to quality.
The problem with Heavy Development Methodologies is that they didn't actually work.
Re: Sequence diagrams, the only good thing UML brought to software development
#234Earlier quoted context omitted.
>There was a lot of good thinking, but one of the adoption problems we had before UML (as tools developers and methodologists) was that many people got a poor introduction to it, and missed the whole point. Not really, UML was doomed from start due to increased time to market metric. And frankly you can read the code if you are working on the already built system. Remember that software usually does not need to be co…
You might enjoy looking a little deeper. For one example: > I'll also concede that state diagrams are good, but well.. they are also quite simple. One of the goals of state modeling is to simplify. A sufficient metamodel will include (in addition to states and transitions on events that people might see in automata theory and misc. CS education) less-simple features like concurrency, superstates, transition guards, m…
It helps in very niche cases - as i said mostly state diagrams, and non-trivial data models when you have to interop with different systems, or define a common data model. Haven't worked with designing protocols, but that's basically a committee work..
That does not change the fact that it is useless for 99.9%, or higher, of typical dev work, for typical dev systems - which are basically CRUD systems with some fluff. This is the biggest barrier for UML to gain traction, and it is completely incompatible with that.
And that's disregarding parity of diagrams with codebase - there's a reason why a lot of codebases reduce comments - as they go out of date pretty fast.
Re: Sequence diagrams, the only good thing UML brought to software development
#235Earlier quoted context omitted.
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
#236Earlier quoted context omitted.
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
#237I still remember of a professor in my university who has written also an UML book. He said it will be the most important thing in your software career and you will use it nearly daily in your future as software engineer. I was sceptical because it was too much preaching for my taste. Turns out I was right. 20 years later: I used it very seldom and definitely NOT in my daily software development tasks. Actually the se…
Re: Sequence diagrams, the only good thing UML brought to software development
#238Re: Sequence diagrams, the only good thing UML brought to software development
#239I 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…
> Class, component, package, activity and state machine diagrams are all useful ways to model the structure and behavior of a system visually. I completely agree with you. It's a good way for other people to present information, for me to look at. I just won't do it myself. It's not only me; and that's why it's dead. I won't do it because the first thing that comes to mind is how it will go out of date in a month, an…
> All those diagrams, when they are complete, correct and up-to-date, do convey what they are supposed to convey.
I spent a bit of time prototyping this recently. It's definitely possible. Rational Rose also had the capability to generate diagrams from code though. I don't remember how good it was at the task though. Was Rational Rose just a very bad implementation?
I find the hate in this chat strange because diagrams are incredibly useful when working through complex problems* and then conveying that information to other engineers. My experience over 20+ years is that a huge portion of engineers can't grok complex problems from code alone.
*Most of my projects are optimizing billion+ row databases, micro-service architectures, and various other scaling challenges.
Re: Sequence diagrams, the only good thing UML brought to software development
#240Earlier quoted context omitted.
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?