3 ms·

Part of engineering culture in general, not just software engineering, is ability to share knowledge though documentation and best practices. If you share the s

Part 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 ago
UML didn't help though because it is never kept up to date with what the code really is
- ivan_gammel 3y ago
  How 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 ago
    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.
    - ivan_gammel 3y ago
      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.
      - bluGill 3y ago
        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
feoren 3y ago
I agree with everything you said until you got to UML diagrams. The problem with UML diagrams is that they communicate exactly the same thing that the code should be communicating. Class diagrams are not higher-level than the code they describe. Instead, communicate high-level intent and interactions.

bluGill 3y ago

UML didn't help though because it is never kept up to date with what the code really is

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

feoren 3y ago

I agree with everything you said until you got to UML diagrams. The problem with UML diagrams is that they communicate exactly the same thing that the code should be communicating. Class diagrams are not higher-level than the code they describe. Instead, communicate high-level intent and interactions.