A while back I got in it my head to write “a people’s history of UML” and interviewed several people about it, including Grady Booch, Bertrand Meyer, and one of the current architects of SysML. The story is a lot more complex than just “Agilists were meany poo-poo heads”. Among other things:

• UML tried to integrate three separate method systems while remaining backwards compatible with all their legacy tooling. That made it very messy and inconsistent from the start.
• There was no text format, except XMI, which barely counts. Between that and its large complexity, the only people who were able to make UML tooling were large software teams, which severely hampered any open-source ecosystem from developing.
• IBM bought Rational in 2003 and did their IBM magic. I had trouble getting Rational Rose working on Windows 10; I don’t think it’s been updated since the mid-00’s.
• Rational and OMG were never that clear on whether UML was supposed to be a modeling tool or a Model-Driven Engineering tool, ie 2-way sync between code and diagrams. Lots of software developers expected the latter and were burned by the lack of any refinement tool or roundtrip properties.
• Software methodology was never a really big thing, and even UML never went fully mainstream. Even in the Bad Old Days of Waterfall the majority of software developed ad-hoc and incrementally.

Unrelatedly, I’m always a little unbalanced by people calling UML a “formal specification”. I guess it is? You can draw an invalid UML diagram. But most of the diagram types are this weird combination of complicated and inflexible that make them poor for actually specifying things. Like how does having a class diagram actually help you? I guess you can trace it to a use-case diagram, but do you really need formal semantics for that?

UML works for a very narrow view of software development. I found that out when I wrote my thesis in OCaml and had to document it in UML. How do you express a curried function in UML? How do you express a simple function in UML that happens to not be attached to an object?

And that is only the tip of the iceberg.

How do you express a complex SQL query in UML? Entity-relation diagrams help modelling the schema, but what about a query with joins and window functions?

How do you express a map-reduce operation in UML? What’s the diagram for filtering a list, then aggregating the results?

How do you express a minimally-complex algorithm in UML (think Sieve of Erastothenes)? Why can’t I use pseudo-code, which beats diagrams every day of the week?

How do you express a reactive user interface in UML? Why do I have to use something like a collaboration diagram, when the state of the interface derives directly the representation of the interface? It’s not the case that the input enables the submit button when it finds itself no longer empty.

How do you express a Prolog program in UML? Do you think the UML committee has ever known about the existence of Prolog?

How do I represent a multi-param generic data structure? For example, a mapping/hash table from A to B, where A and B are arbitrary types.

And then we ignore the old problem of documentation and software diverging over time, and having to update the documentation when the software changes.

UML comes from an era where Object Oriented (Obsessed?) Design was the whole world, and everything that wasn’t OOD was being forced to not exist. In this era, Architects would draw UML diagrams and cheap Indian code monkeys would do the coding, because we thought that code monkeys would be cheap and replaceable. This was perfect for the MBAs because programmers started to be annoying by not delivering on the expected deadlines, and claiming about the algorithms, the damned algorithms. We wanted to replace them with cheaper and less-whiny ones.

Turns out that the details of the system are in the code, not in the diagrams, and only the trivial parts of the system would be expressed in diagrams, and the devil is in the details. But this makes programmers non replaceable and fungible, because the better ones can express algorithms that the worse programmers will never understand. And many times, you need these better algorithms.

All this makes UML not anymore the silver bullet for bodyshops. The broken idea of hiring 1 architect and 100 code monkeys from the consultancy just doesn’t work, because the architect is not expected to dig in the details, and the 100 code monkeys will just make a mess of the details.

UML was dead on arrival when it ignored most of the details of Software Development. Doesn’t mean though that some parts of UML can be salvaged, such as sequence diagrams, state diagrams, or entity-relation diagrams. But trying to model in UML an arbitrary problem and solution is likely to become wrestling with the language to express anything minimally complex or different.

I felt this one. I haven’t been doing this, relatively, that long but it feels like we are eschewing formal documentation and planning for a more fly by the seat of our pants, get it right with enough iteration approach. I’ve talked to a few “technology savvy investors” in the past few years that have told me that software architects are an antipattern.

On the one hand the people against a more formal architecture approach might be right. If you break your features down to such manageable chunks that they can go from zero to hero in production in a sprint do we need need a full design process and documentation that will end up wrong or out of date before anyone has a chance to fix a bug?

I think the problem ends up being with the struggle of maintaining a cohesive architecture across all of these manageable l, hopefully vertical, slices of functionality. I’ve come into a few shops who have followed a low/no documentation route (“The user story is the documentation!” Said the project manager) and indeed they ship code fast but by the time I get there we get tasked with trying to build a unifying style or standard to move everything to because the original developers are gone/dead/committed to an asylum for their health and no one is willing to make changes to the legacy codebase with any confidence and ticket times are climbing.

So where is the middle ground? I would be happy to never have to create another 10+ page proposal, print it out and defend it in front of people who are smarter than me, and know it but there is something missing in modern software development and I think it’s some sort of process of getting our bad ideas out in the planning phase before writing code. Formal methods for sure fill this role but no one has the time outside of the “if my code fails someone dies” crowd.

I guess this is a long winded way of saying “I use formal planning to get my bad ideas out of my system before I create software that works but breaks in subtly or is just flat out wrong.

Why masala? Because they are informal; they cover multiple dimensions at once, they may be both structural and behavioural, logical and physical.

A bit tangential but I don’t really get why you’d call these diagrams “masala”. In the usage I’m familiar with, masala is key to good flavor and spice, which, metaphorically I think you’d want in your diagram.

For some time now i have thought the prevailing development methodology is “hack it till it works”, labeled under the more acceptable term “agile”.

An alternative name in terms of requirements analysis is “Marco Polo” development, named after the popular swimming pool game.

UML or any formal equivalent simply isnt required for such a methodology.

I’ve never been a fan of UML just because I’m not a visual thinker, but I definitely agree that formal specifications have fallen out of favor.

My charitable take is that a big part of it is because our tools are getting better, such that the cost of being somewhat wrong is often considerably lower than the cost of trying to be precisely correct. When iterating on a piece of software meant a new months- or years-long development cycle, it really really paid to make sure you got it right the first time. But now? “Sure, we should be able to change how that works in time for the weekly production release.”

My less-charitable take is that it’s because in enterprise and consumer software, we’ve sort of decided that specs should be written by product managers who often have little or no training or background in rigorously specifying a system and are instead focused almost exclusively on high-level “user stories” that don’t require thinking in fine detail, or on UI mockups that don’t require writing down precise business rules.

That said, though, there are still contexts where you see people take up-front design discussion pretty seriously. Of course there are obvious candidates like aerospace, but also, for example, the processes some programming languages have in place to manage their evolution (JEP, PEP, etc.) involve a lot of design discussion before anyone is willing to review any code.

I’ve never really found a good use for component diagrams or activity diagrams. Component diagrams are too fine-grained in UML (what I really care about are whole software components, not classes, which might not even exist in my language), and activity diagrams are pretty much just restating code in diagrammatic form.

But UML sequence diagrams are incredibly useful! For the type of work I do, which is mostly projects with a lot of services communicating over gRPC, I don’t think there’s any better way to understand what’s going on and communicate it clearly.

Entity-relationship diagrams are also still useful, although not technically part of UML.

Take the useful stuff, throw away the useless stuff…

UML was a flimsy excuse to sell obscenely-priced training, documentation, tooling, and consulting. We caught on. That’s it.

Typo: “Lots of thot leaders…”

Or, uh… maybe not?

I’m not familiar with UML, so this question might be unwelcome considering a bit more research might get me to my answer. But why is the flowchart in the author’s second image (the millionaire question) rigged? It seems clear to me assuming that the step numbering is meaningful. That is, step one followed by either step 3 or step 2 and then 3. How does UML solve the ambiguity?

This is an Agile/management driven approach and it sounds about right, but I wonder if it’s also from the tooling perspective. The average business programmer is less Java object hell, more JavaScript slurry.

The quotes in the title are there for what? Emphasis? That’s not what quotes do: https://www.dailywritingtips.com/punctuation-errors-quotation-marks-for-emphasis/