UML diagram for the DDD example in Evans' book

All agile does is ask you to iterate, which means updating your design, your code, and your tests & documentation, as you learn.

Please read the agile manifesto again, and actually apply it. It does not say we don’t do design at all. Never did.

Had an intern a year ago whose school forced them to go the whole nine yards with UML. Our company gave them a project to build, and their school made them draw use-case diagrams, class diagrams, sequence diagrams, and activity diagrams, before the student was allowed to write any code.

This was a waste of everyone's time, and we gave the school some choice feedback which I'm sure they'll ignore.

Sequence diagrams are still used quite a lot, and for good reason, they're incredibly useful. I see simple class diagrams quite frequently as well, but without the poorly designed arrow nonsense (shaded? open? closed? argh!).

Good diagrams are an art form though, just like other forms of good documentation. There is a big difference between a diagram being a normative source of truth, and being a good tool.

Take this diagram as an example: https://takaakit.github.io/uml-diagram-for-ddd-example-in-ev...

* Nearly the top half is taken up by relations which aren't especially helpful, and would be better expressed on the entities themselves.

* The "Location" type looks like the primary type in the system based on nearly half the types in the system connecting with it, creating a nest of graph edges. However, this is likely a simple and immutable record type. If the entities in this diagram had attributes (e.g. like a class diagram), you could refer to it by name, and greatly simplify the cognitive load in understanding this picture.

This is the sort of diagram that gets generated from code, and is at the level of specificity needed to generate code from a diagram. It also isn't very useful for using the model to convey the system to a person - a developer might be more comfortable reading the code rather than looking at a picture generated from it.

IMHO, that split focus in UML between people and tooling greatly reduced the overall usefulness and understanding of the system. It gave UML a bad reputation. Training on MDD tools prevailed over providing a baseline of common nomenclature to enable "team cave drawing on a whiteboard", which has no commercial tooling or market other than the whiteboard and markers.

The areas where visual languages have a bit more prevalence are on the business modeling side, including things like network architecture diagrams.

It is a bit of a shame - going through a set of use cases while iteratively improving the architecture by improving a set of class, sequence and ECB diagrams is something I always found to be crazy efficient vs diving immediately down to prototype code.

Too bad, they aren't that popular to document behaviour, because sequence diagrams really don't convey that much.

For example timeouts are very neatly described in a harel state chart. How will one describe timeout and timeout handling in sequence diagrams.

Then the company progressed and eventually we got to market fit and for two years the team and I were dealing with this increasingly burdensome complexity that we were not reaping any rewards of. Then one day we had enough and a colleague redesigned the system to ditch the extra complexity resulting in a much more elegant design that was easier to reason about.

That bliss continued for less than a year, until some customers asked for a particular report that we needed to generate based on a structure of the information that was now no longer present. We had to redesign it again, migrating was super painful and involved a temporary workaround that basically involved an extra branch on literally every piece of code that touched the inspection system.

In retrospect, I still don't know how I could have convinced the team that the complexity was something we needed when no customer required it for 3 years. Especially when the colleagues who took over that system from me had gained much more experience and expertise in the domain than I had since I had designed the original.

It would probably have been better if I had recorded the requirement that prompted the complexity, but had not actually implemented it as no customer had actual need for it at the time. Then we would not have had to deal with the complexity the first three years, and then evolved the product when the need arose.