61–70 of 77 posts
What happened to UML? I remember it was everywhere in enterprise computing 20 years ago but seems to have disappeared now. Is it still around or did it go the way of SOAP, Java Applets? If not, what has replaced it?
Agile and scrum and iteration saw them off.
Good UML is really simple UML. "Then what about complex things? Can't make everything simple" Do partial diagrams. Simplify or skip things your team already knows. Also, great UML is no UML. Sometimes the code itself is short and clear enough, requiring no diagram (of course, not all diagrams are about code... but use case diagrams are rare these days anyway). Also, use cases and use case diagrams are great. Also, pe…
I very much like your comment. It describes practical use of diagrams. In the past, I've included diagrams for a particularly complex state in the comment on top of my code. It certainly doesn't describe the whole system, or even the complete state of that code. And I expect that someone will delete the comment at some point. That's all fine.
I remembered once I drew ASCII diagrams for a particularly tricky algorithm in the top of its unit test methods. And people indeed deleted them.
Earlier quoted context omitted.
> try to find an error in the diagrams. Easy peasy, it's the 3rd blue line above the purple line /s https://github.com/takaakit/uml-diagram-for-ddd-example-in-e... I can't believe someone took time to generate such a thing, as if it is useful to anyone
It’s a great demonstration how unrealistic it is to use it. If it is this complicated for a demo project for the purposes of the book, in my opinion, it shows it’s completely inadequate for handling anything remotely real. Project ongoing for five years, 10 devs on the team, each year two resigns and two joins, some good, some mediocre, can you imagine them mess this will be? And that’s not even a large project, it’s…
What happened to UML? I remember it was everywhere in enterprise computing 20 years ago but seems to have disappeared now. Is it still around or did it go the way of SOAP, Java Applets? If not, what has replaced it?
It is pretty much alive in big corps.
I imagine it got out favour on hipster coffee shops coding their next big idea, rewriting multiple times, instead of validating their ideas in first place.
Github supports UML diagrams in their markdown for a reason.
Earlier quoted context omitted.
I think its abandonment is related to the adoption of agile methodologies. UML was used to describe systems from day one. Agile methodologies came in, claiming that we don’t need it.
You still need to describe systems in agile. 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.
What happened to UML? I remember it was everywhere in enterprise computing 20 years ago but seems to have disappeared now. Is it still around or did it go the way of SOAP, Java Applets? If not, what has replaced it?
UML and waterfall/Big Requirements Up Front/analysis paralysis all ride in the same car. Agile and scrum and iteration saw them off.
Earlier quoted context omitted.
UML was a scam really. They took a lot of very useful diagrams and created a absolute behemoth of unproven system to develop software and sold it. The diagrams are very nice and useful. But the UML as a process, if taken literally, it a total disaster.
One of the creators of UML, Booch, has said so himself that it was taken to a point where it should never have. Interesting interview: https://youtu.be/u7WaC429YcU?feature=shared
I used to work heavily in this kind of system modeling (developing tools for it, and dogfooding), and still use it when high-value for figuring out or communicating an aspect of a system. Here's a challenge, to help appreciate the nature of these: try to find an error in the diagrams. It's usually harder than you might think, since, even when you know the notation and metamodel semantics, it's information-dense talki…
One of my more painful design mistakes happened in this sort of way when designing a system for recording inspections. I interviewed multiple inspectors and came up with a representation that was a little bit more elaborate than I would have hoped, but it at least captured all information I believed. Then the company progressed and eventually we got to market fit and for two years the team and I were dealing with thi…
I like your idea of capturing some requirement(s) that motivated the extra complexity, and retaining those requirements in a place they'll be seen and consulted when any new release planning and architecture happens.
This seems related something I do when scoping an MVP or release: work through the requirements breakdown, and mark the things we considered but decided not to do in that release (the "NON-Reqs"). Keeping them in the document gets everyone who looks at it up to speed, so we don't keep rehashing, and also makes it very clear to people that this thing someone told them the system would do is definitely not happening (a very-very-very common miscommunication in some companies).
But if a NON-Reqs suggests some future growth affordances that I think are important to try to include in the new architecture work now, to avoid/reduce very expensive refactoring/rewrites/rearchitecture in the near future, maybe some of those NON-Reqs should be moved to bulletpoints in a requirements section like "Architecture Growth Affordances", and become medium-priority requirements not to preclude in the architecture. Where it can be triaged, prioritized, and traced like any other requirements.
I like that idea a bit, but a few problems:
* Someone might get confused that you're promising to deliver that in a future release.
* Someone might blame if, when the future release planning comes, you say that feature will take a lot of work, but they thought you already did most of the work for it in the previous release.
* You'll need everyone involved to find the right balance of how much to think about about this release, and how much to keep in mind ability to do future releases. By default, people will have a lot of trouble with both kinds of thinking.
* A lot of these architectural decisions with growth in mind will happen after the requirements are locked in, and making frequent changes to that set of requirements is a very confusing precedent to set. (For example, most people won't take the commitment to the requirements seriously, if they think things can just be tossed into it later as needed, or if they think you're just doing incompetent theatre. You want them to get the idea "anything that isn't committed to in the requirements, isn't happening in the release; so everyone think and agree hard together now, so that we'll all be working effectively and efficiently towards the same viable release". Only after everyone gets that, do you introduce the flexibility.)
Maybe those requirements should go to a place for "anticipated future requirements" (but that isn't only a backlog of "candidate requirements"), in that it can be referenced for traceability when you make an architectural decision with future options in mind?
Or, the fallback (which I've used countless times) is to document with the architecture (embedded in the code, or in other canonical arch docs) the rationale for the decisions. Then, when someone goes to change the architecture, that information is hopefully somewhere they'll see. (This assumes that the person changing the architecture is a smart professional.)
Apropos of nothing, all of the major ai models have gotten really good at turning a pdf or document into uml Not great, mind you. 80% of the way there still saves an hour of your time tho
How about we ditch the AI slop
You’re free to spend hours building and modeling in UML
I’ll happily shave 2/3rds that time off with AI