UML is also good for another thing, and that's been endless amounts of blog spam and article fodder
and consulting fees!
Sequence diagrams, the only good thing UML brought to software development
331–340 of 427 posts
Re: Sequence diagrams, the only good thing UML brought to software development
#332Earlier quoted context omitted.
"we are lazy assholes who can't keep docs up to date, therefore docs are useless" Is essentially the argument i see over and over again. And every time i start a new project and that project has docs or uml or whatever I appreciate it. Even if it is a bit out of date, it's way better than nothing. In my opinion, every project should have a readme file with instructions for running the project locally, and ideally als…
> "we are lazy assholes who can't keep docs up to date, therefore docs are useless" Rather: managers do not highly value work on documentation, so many programmers care little about it. If writing good documentation was valued more by managers than implementing feature stories, the situation would be different. Incentives do matter.
We are the engineers. It is up to us to tell non technical managers what's important. They don't know shit, they're just there to handle the shit we don't want to handle, like talking to clients or upper management or whatever.
It's all just bad excuses for not doing work properly. Writing clean and well documented code very quickly becomes faster than writing a tangled undocumented mess.
Re: Sequence diagrams, the only good thing UML brought to software development
#333I 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…
We also moved to framework heavy development where you write classes that plug into frameworks. So a POJO here and a POJO there… (everywhere a POJO) that are managed by a framework and exist only to extend the framework are marginally useful. A UML class diagram for a Spring Batch transformer that’s cobbled together from an existing CSV reader component, just isn’t that interesting or necessary.
Re: Sequence diagrams, the only good thing UML brought to software development
#334Am I the only one who finds sequence diagrams hard to read?
Re: Sequence diagrams, the only good thing UML brought to software development
#335A strange conclusion for something that has been around for so long. It's a bit like saying the horse-drawn carriages are no good because cars.
When UML was released, waterfall was pretty much the only model for Development and was understandably slow, expensive and risky. UML with processes like UP were used to bring in some order and standardisation to the picture. I used to use it a lot and it was really annoying because I just wanted to code but even in the early 2000s, release cycles were long (2-4 weeks) and mistakes would take a long time to spot and rework.
Like all tools, we didn't always use it and we didn't always add 100% detail but we did use it. I don't use it as much any more because code is quick to produce, quick to review, to merge, to fail and to rework. That doesn't mean we shouldn't design up-front but there are many more use-cases where the time and effort of design is just not worth it.
I still use class diagrams sometimes, although they are not really something specific to UML but I have also used state diagrams, again for specific scenarios, but let's just understand tools and decide when and where they are useful.
Re: Sequence diagrams, the only good thing UML brought to software development
#336I 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…
Maybe UML can find a new life with ChatGPT. Maybe it can fulfill the promise of generating code out of diagrams. UML seems like a fine way to organize prompts.
Re: Sequence diagrams, the only good thing UML brought to software development
#337Earlier quoted context omitted.
Maintaining documentation. UML cannot go even one developer-week without being updated, but the developer will often not do that. By the time your UML is a month out of date it is useless at best, and misleading at worst.
This has nothing to do with UML. Ad-hoc diagrams or plain text descriptions become outdated at the same speed, which depends only on the level of detail that you put in documentation and not on the format if it. If you cannot keep up with the changes in the code, you are choosing the wrong level of detail, that’s it.
Ad hoc diagrams are much more likely to be tossed in the trash can after a week. If you keep them longer than the same problems apply. If you only keep them for a week than ad hoc is good enough as everyone still remembers what the symbols mean from when you created it, and the next time it won't matter that the symbols mean something different
Re: Sequence diagrams, the only good thing UML brought to software development
#338Earlier quoted context omitted.
"we are lazy assholes who can't keep docs up to date, therefore docs are useless" Is essentially the argument i see over and over again. And every time i start a new project and that project has docs or uml or whatever I appreciate it. Even if it is a bit out of date, it's way better than nothing. In my opinion, every project should have a readme file with instructions for running the project locally, and ideally als…
It's not a question of laziness. People just need to use better tools to generate docs and fail CI if the implementation and docs diverge. I used to hear people say the same thing about laziness about code style before reformatting/linting tools became standard.
Name me a tool that verifies UML and code are up to date in ci. Now lets add requirements that it is good UML.
Don't forget that some details shouldn't be in UML.
Re: Sequence diagrams, the only good thing UML brought to software development
#339Earlier 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…
I tend to agree about the time thing, namely that people aren't given enough of it to sit down and take their time with design decisions. If you squint you can kind of see that "software architects" are a business's way of creating a "solution" to this problem, but with lackluster results. That said, I've been at places where management did a pretty good job of making sure that there was enough time to do this kind o…
That's fair, and a good observation.
I'm not sure what to make of it as far as general narrative.
If people are creating stuff they don't really care about, of course it won't be very good? And there's a lot of money spent paying people to build things that honestly nobody would reasonably care much about?
One way or another, the pining for a software engineering world where we all collaborate on creating things that are maintainable products with high-quality user-facing experiences, and have the time to do that... well, that's not the one we've got.
Re: Sequence diagrams, the only good thing UML brought to software development
#340I 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…
Does anyone else find the agile way of doing things just ends up with lots of increments and no big picture of how the system should be or where it should be going? There also seems to be a with with waterfall that it's a one way process and you can't do iterations.