While UML as a sketch had some use, it was a very predictable disaster when people tried to use it to automate away the 'coders'. It automated 5% trivial work that bothered nobody, while getting in the way when things got medium hard.
I wonder if the current crop of low code tools learned from the whole UML story. Any chance things will be better this time?
Diagrams are good for representing structure, and inherently less good at representing behaviour (as mentioned in the article). I recall that in the early 2000s some UML tool venders were pushing "round-trip automation" as a way of tackling this problem; basically you'd model your business domain with some class diagrams, generate some boilerplate code, write code for the actual behaviour and then the tool would magically suck all the behaviour logic back into the diagram. It sort of worked, for a couple of passes, until the tool failed to capture the precise semantics of some perfectly valid code (which was probably inevitable).
I'm hoping that the (somewhat-fine) distinction between no-code and low-code is made with the same problems in mind, that is, an acknowledgement that code is quite often the best way of expressing the behaviour of a system.
I wonder if the current crop of low code tools learned from the whole UML story. Any chance things will be better this time?