3 ms·
> 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 engi
by 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 agoUML 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 agoMature teams document their code
- ivan_gammel 3y agoPart of engineering culture in general, not just software engineering, is ability to share knowledge though documentation and best practices. If you share the source code, you communicate your solution on a very low level. It is often necessary to zoom out to see the big picture and there visualization helps. You can create ad-hoc diagrams, but their expressive power is low: without a convention it’s basically just space, text, arrows and generic shapes. To increase the expressive power you need a visual language in which different shapes and lines have some semantics. And here comes UML and other diagram languages. If you are not using them, it is likely that you are not communicating efficiently. Can a mature team fail at communication? I leave the answer to you.
- bluGill 3y agoUML didn't help though because it is never kept up to date with what the code really is
- ivan_gammel 3y agoHow was it supposed to keep up? The most popular programming languages did not introduce concepts that are too hard to reflect with UML. Or do you mean the problem of maintaining documentation?
- bluGill 3y agoMaintaining 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.
- ivan_gammel 3y agoThis 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.