4 ms·

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 most

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.

pydry 3y ago
>I think it mostly depends on maturity of the team yep. kids out of college feel most inclined to use it.
taeric 3y ago
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.
- ivan_gammel 3y ago
  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.
  - taeric 3y ago
    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.
feoren 3y ago
> I think it mostly depends on maturity of the team and engineering culture, whether UML is used or not. I suspect that's true: teams with a very immature engineering culture probably do use a lot more UML. It's a good way to feel like you're doing something useful instead of actually doing the hard part. Mature teams write code.
- prepend 3y ago
  > Mature teams write code. Sounds very Dunning-Krugerish “smart people like me do X and not smart people do Y” Coding and documenting aren’t exclusive. Modeling is part of documenting. UML is a type of modeling. I would think effective teams will want to build good software. And to build good software they’ll want to capture requirements, communicate with other teams, and test their software. Design helps with this and is part of coding. At the end of a successful day, I should have some updated models, some code, and some running software. If someone wants to see what I did, they’d likely read through different parts. Just like trying to figure out a stage by just reading models sucks, so does trying to figure it out by just running the software.
  - feoren 3y ago
    UML is not documentation, it's code for people who can't read code. UML diagrams offer no additional information to someone who already can read code (and write readable code). They are training wheels. Mature bike riders don't use training wheels. Mature teams don't write UML -- they write code instead. Other forms of documentation have their own tradeoffs, but I was not discussing those. You're the one who automatically equated UML with all possible documentation. > to build good software they’ll want to capture requirements, communicate with other teams, and test their software UML is awful at all of this. > At the end of a successful day, I should have ... > “smart people like me do X and not smart people do Y” You don't see the irony here?
- ableeb 3y ago
  Mature teams document their code
- ivan_gammel 3y ago
deleted 3y ago
[deleted]
marcosdumay 3y ago
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 changes, like for workflows), and thus everybody uses the UML one. But yes, people don't remember about deployment diagrams. Those are used a lot.
- francois14 3y ago
  Class diagrams are a good way to detect circular dependencies.
  - marcosdumay 3y ago
    If your class diagram is comprehensive enough to get circular dependencies, then I'm completely sure¹ nobody will use them for anything. Computers are much better at this kind of checks anyway, and they don't need diagrams. 1 - Instead of "well, maybe it's possible despite I never seeing it"
- ivan_gammel 3y ago
  > 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.

pydry 3y ago

>I think it mostly depends on maturity of the team yep. kids out of college feel most inclined to use it.

taeric 3y ago

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.

ivan_gammel 3y ago
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.
- taeric 3y ago
  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.

feoren 3y ago

> I think it mostly depends on maturity of the team and engineering culture, whether UML is used or not. I suspect that's true: teams with a very immature engineering culture probably do use a lot more UML. It's a good way to feel like you're doing something useful instead of actually doing the hard part. Mature teams write code.

prepend 3y ago
> Mature teams write code. Sounds very Dunning-Krugerish “smart people like me do X and not smart people do Y” Coding and documenting aren’t exclusive. Modeling is part of documenting. UML is a type of modeling. I would think effective teams will want to build good software. And to build good software they’ll want to capture requirements, communicate with other teams, and test their software. Design helps with this and is part of coding. At the end of a successful day, I should have some updated models, some code, and some running software. If someone wants to see what I did, they’d likely read through different parts. Just like trying to figure out a stage by just reading models sucks, so does trying to figure it out by just running the software.
- feoren 3y ago
  UML is not documentation, it's code for people who can't read code. UML diagrams offer no additional information to someone who already can read code (and write readable code). They are training wheels. Mature bike riders don't use training wheels. Mature teams don't write UML -- they write code instead. Other forms of documentation have their own tradeoffs, but I was not discussing those. You're the one who automatically equated UML with all possible documentation. > to build good software they’ll want to capture requirements, communicate with other teams, and test their software UML is awful at all of this. > At the end of a successful day, I should have ... > “smart people like me do X and not smart people do Y” You don't see the irony here?
ableeb 3y ago
Mature teams document their code
ivan_gammel 3y ago

deleted 3y ago

[deleted]

marcosdumay 3y ago

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 changes, like for workflows), and thus everybody uses the UML one. But yes, people don't remember about deployment diagrams. Those are used a lot.

francois14 3y ago
Class diagrams are a good way to detect circular dependencies.
- marcosdumay 3y ago
  If your class diagram is comprehensive enough to get circular dependencies, then I'm completely sure¹ nobody will use them for anything. Computers are much better at this kind of checks anyway, and they don't need diagrams. 1 - Instead of "well, maybe it's possible despite I never seeing it"
ivan_gammel 3y ago
> 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.