I don’t think the “using UML” phrase is significant in that statement.
It seems weird that “No one is willing to waste time” updating diagrams, yet everybody who encounters a new large code base starts drawing diagrams.
It’s not clear to me whether making it easier to update diagrams or making it required (say by having the diagrams be part of the source code, without which the code won’t compile. There have been several attempts writing such systems, but none has become popular) will help there. Maybe, the act of drawing such diagrams (as opposed to looking at them) is essential for learning a code base.
I usually start drawing diagrams because the existing ones are difficult to read.
This is another problem with UML in practice, that drawing diagrams is a skill, a bit similar to writing code in the sense that it is possible (and quite frequent) to have "spaghetti diagrams" with dozens of classes on one screen connected by long zigzag lines you need to carefully trace by finger.
The solution, as usual, is "divide and conquer", where you create a separate diagram for user management, another diagram for invoices, yet another for... whatever the application does. Okay, people do it partially, like they split 100 classes into two diagrams with 50 classes/tables each, but good design would be more like 10 diagrams with 10 classes/tables each.
Another problem is that the UML language cannot capture things specific for the project. For example, suppose that 80% of your classes have fields like "date_created", "date_modified" etc. How are you going to handle this? If you write those fields everywhere, you get lots of repetition. If you don't write them, you miss a potentially useful information.
With an informal diagram language, you could create a project-specific convention, for example a small clock icon in the corner would imply presence of "date_created" and "date_modified" fields -- and the icon itself would also be explained somewhere. A bit like graphical domain-specific language.
> With an informal diagram language, you could create a project-specific convention, for example a small clock icon in the corner would imply presence of "date_created" and "date_modified" fields -- and the icon itself would also be explained somewhere.
The UML spec actually has support for this. It defines a special kind of 'inheritance' between diagram elements and ways to represent it, including iconically.
> This is another problem with UML in practice, that drawing diagrams is a skill, a bit similar to writing code in the sense that it is possible (and quite frequent) to have "spaghetti diagrams" with dozens of classes on one screen connected by long zigzag lines you need to carefully trace by finger.
This still comes to a head with Unreal Engine Blueprints.
On that note, I really wish we had tooling for automatically generating diagrams from existing code. Kind of an interactive query language:
"Starting here [main.cpp :: Start()], how do I end up here [Frobnificator.cpp :: FrobnifyQuux()]?" - should give me a sequence diagram like this one: https://s.plantuml.com/imgw/img-f05ecfe23bf545656a3a1f66b2a9.... And then I should be able to narrow it down, skip selected functions or classes.
I once spent over a day drawing such a diagram (much larger) for the core system of a large codebase I started working on. I did it by manually stepping through a codebase and making notes as I went, in PlantUML format. It ended up being tremendously helpful, as parsing a diagram like this is much faster than parsing textual representation. And a year later, when I had to revisit that part of the code again, despite being not entirely accurate, the diagram was still very helpful.
Same for other types of diagrams - class, state, component, activity, timing diagrams. The tools we have all have enough information (e.g. Clang definitely understands C++ codebases well enough that it should be able to spit out the aforementioned sequence diagram between two given points), but I'm not seeing them used this way.
> It seems weird that “No one is willing to waste time” updating diagrams, yet everybody who encounters a new large code base starts drawing diagrams.
[citation needed]. I got a new job fairly recently, we’ve got a massive codebase, and I never had the urge to draw any diagrams. (We’ve got zero diagrams as part of our docs as well.)
> yet everybody who encounters a new large code base starts drawing diagrams
I draw a lot of diagrams when exploring code, but they are almost never uml, because usually I look at code searching for a particular information, and only draw what is relevant to that search with varying level of details.
If I was to draw everything (no matter the format) - it would become a huge mess with signal-to-noise ratio very close to 0, at that point I might as well just read the whole codebase.
It seems weird that “No one is willing to waste time” updating diagrams, yet everybody who encounters a new large code base starts drawing diagrams.
It’s not clear to me whether making it easier to update diagrams or making it required (say by having the diagrams be part of the source code, without which the code won’t compile. There have been several attempts writing such systems, but none has become popular) will help there. Maybe, the act of drawing such diagrams (as opposed to looking at them) is essential for learning a code base.