Why UML “Really” Died(buttondown.email)
buttondown.email
Why UML “Really” Died
https://buttondown.email/hillelwayne/archive/why-uml-really-died/
200 comments
This.
Back then, anything that could be used to increase a manager's department budget could be the basis for a business. There was a job, "System Analyst", whose output was supposed to be stuff like that. Programmers were supposed to just code what the diagrams System Analysts produced said, and not try to think.
There is still an ISO Standard for regular flowcharts, and lots of DoD contracts require delivery of ISO Standard Flowcharts, so there are tools to automatically generate flowcharts from source code, which are printed out, delivered, and dropped in file drawers in dusty warehouses.
Every five or ten years ISO issues a new Flowchart Standard. It has been suggested that they issue a Standard that says any old blank sheet of paper meets the Standard, to save a lot of money on printing them out and storing them. It hasn't happened yet.
It would not be surprising if there were a zombie ISO UML Standard, and contracts requiring software be delivered with conforming UML.
Back then, anything that could be used to increase a manager's department budget could be the basis for a business. There was a job, "System Analyst", whose output was supposed to be stuff like that. Programmers were supposed to just code what the diagrams System Analysts produced said, and not try to think.
There is still an ISO Standard for regular flowcharts, and lots of DoD contracts require delivery of ISO Standard Flowcharts, so there are tools to automatically generate flowcharts from source code, which are printed out, delivered, and dropped in file drawers in dusty warehouses.
Every five or ten years ISO issues a new Flowchart Standard. It has been suggested that they issue a Standard that says any old blank sheet of paper meets the Standard, to save a lot of money on printing them out and storing them. It hasn't happened yet.
It would not be surprising if there were a zombie ISO UML Standard, and contracts requiring software be delivered with conforming UML.
The problem is system analyst is a useful job only if they don't have to worry about all the details of the helpers and incidental data field and can focus on the high level parts that matter. In the mean time programmers need to add those little helper classes as implementation details, and they instead of to spend a week doing some formal request to the system analyst for something that could be done in an hour if they were allowed to think. And of course programmers have to think anyway.
Maybe I’m getting primed to be eaten by zombies by saying this, but I think UML was trying to do something valuable.
A tool which could create visual diagrams for logic flow and abstraction would be amazing. After parsing a large project, many people create a mental map which feels quite close to some sort of visual diagram. If someone could figure out how to represent those models visually, I think it’d be a lot easier to identify good abstractions for a problem and its likely evolution vs bad abstractions for a problem and its likely evolution.
A tool which could create visual diagrams for logic flow and abstraction would be amazing. After parsing a large project, many people create a mental map which feels quite close to some sort of visual diagram. If someone could figure out how to represent those models visually, I think it’d be a lot easier to identify good abstractions for a problem and its likely evolution vs bad abstractions for a problem and its likely evolution.
The problem wasn't the idea, a visual diagram for logic flow is a good idea but your IDE can do that from your code better than the over-engineered idea of UML. UML had another problem, it reversed the way programmers work. As a programmer you start with a rough sketch (hand drawn diagrams and/or some prototype code) and iterate through that along with the client until you have what they want. UML (at least the way it was taught in my university) assumed that the client knew exactly what he wanted and that as a developer you could get your system designed perfectly on a diagram before writing a single line of code. When you tried to translate that into code you realized that your design wasn't as good as you thought, you had to make changes and doing that required going through a lot of bureaucracy (and change requests) that only served to hinder your progress. The automatic code generation promised by Rational wasn't as good as promised, it was close to useless and their software and UML basically expected you to program in enterprise Java, trying to fit a less enterprise OO language there was pure pain and resulted in very messy designs.
UML isn't taught that way any more. It's still mandatory in programming courses and waterfall(ish) programming projects, but it's also emphasized that iteration with clients is a good thing if you can do it, that the clients don't actually know that they want, that you're unlikely to get your software right the first time, and that 90% of software projects end up failing anyway.
The problem is keeping those diagrams correct. I've worked where the UML was the code, and it worked because the visual models were up to date. Every monday I'd print on poster sized paper the latest models to paste on my cube wall. They were good enough for the rest of the week, but by the next week there were different enough as to be worthless.
I've never seen UML actually work anyplace else. Either the models are out of date, or they are only up to date because you force people to go back to maintain the models after the code is working. This latter of course fails, why would management want to pay someone do maintain models when not only is the code working (well at least partially) for the testers, but the person who is assigned to do it doesn't want to.
I've never seen UML actually work anyplace else. Either the models are out of date, or they are only up to date because you force people to go back to maintain the models after the code is working. This latter of course fails, why would management want to pay someone do maintain models when not only is the code working (well at least partially) for the testers, but the person who is assigned to do it doesn't want to.
What were the advantages and disadvantages of programming in UML rather than, for example, Java or Python? In https://news.ycombinator.com/item?id=26959307 I blasted it as "a fraud" because of clearly exaggerated claims made for its power that went far beyond anything available; how did its power compare in practice to other programming languages?
Another Turing complete language. The one I used compiled to unreadable c++. It was easier to see the big picture because all the models were visible. However in the end it is all syntax.
One problem is that there are many such visualizations, each of which has its own advantages and disadvantages for specific purposes. Visual syntaxes also scale very badly with increasing complexity, so it's very unlikely that a "large project" could be usefully represented by a handful of diagrams. UML seemed to have very clear problems due to both of these issues.
I think the fact that there’s no underlying physical object might be the bigger problem. Mechanical and electrical diagrams seem to scale quite well with complexity. They’ll get cluttered/you might need to break them into pieces, but they’re still intelligible and seem much easier to keep accurate and useful than most software diagrams.
And it's not like this hasn't been tried with varying degrees of success prior to UML (IDEF/IDSS, IORL, even arguably arguably CORBA, etc.)- it just happened to get a lot more traction, and waste countless billions on worthless busywork.
Objects sound like a good idea, and set the propeller-beanied programmer geeks (especially the academic ones who can't deal with the real world anyway) all aflutter, but really aren't worth the trouble in practice.
> I think UML was trying to do something valuable.
So? Doesn't mean that it was actually doing anything useful 99.99% of the time.
So? Doesn't mean that it was actually doing anything useful 99.99% of the time.
The claim that the method was not useful seemed a little too generic. Depends on what was meant by “method”, but I took that to mean a method of software development and communication that uses lots of abstract detailed visual diagrams. I don’t think that whole idea should be abandoned because UML had problems.
I wholeheartedly agree. UML never really lived, and I will say the reason is that it doesn't solve a problem that needs solving.
It's supposed to be a universal (visual) language. Two problems, in the real world the way it was used and, more often than not, misused it was far from universal. I mean that deployment diagram is really kinda of more of an object diagram or class diagram, except for wait why are you using the open arrows there??? What? Guess what? I can draw things in visio too. If I want to describe a sequence, I can draw a timeline or sequence diagram-like without any ritually specialized visual nomenclature. And it would be a lot more universally understood because nobody really knows the fine details of UML in the first place.
The fact that what I mean by arrows and boxes is unique to the situation and not a standard does not in any way reduce my ability to describe and communicate a design with arrows and boxes. Communicating a design via words, language, OR graphics is an art and it is not helped by a crude "universal" visual nomenclature that is in reality widely misused.
Secondly, nomenclature isn't the problem in the first place. Design is. Communication of the design is too. UML is more of a hindrance to these than a benefit. It's like the difference between a fine art portrait and an Identikit in the hands of a random wage slave with bad taste.
It's supposed to be a universal (visual) language. Two problems, in the real world the way it was used and, more often than not, misused it was far from universal. I mean that deployment diagram is really kinda of more of an object diagram or class diagram, except for wait why are you using the open arrows there??? What? Guess what? I can draw things in visio too. If I want to describe a sequence, I can draw a timeline or sequence diagram-like without any ritually specialized visual nomenclature. And it would be a lot more universally understood because nobody really knows the fine details of UML in the first place.
The fact that what I mean by arrows and boxes is unique to the situation and not a standard does not in any way reduce my ability to describe and communicate a design with arrows and boxes. Communicating a design via words, language, OR graphics is an art and it is not helped by a crude "universal" visual nomenclature that is in reality widely misused.
Secondly, nomenclature isn't the problem in the first place. Design is. Communication of the design is too. UML is more of a hindrance to these than a benefit. It's like the difference between a fine art portrait and an Identikit in the hands of a random wage slave with bad taste.
Sequence diagrams are very useful. Flow charts and state diagrams are also useful but less so in my experience.
If your inheritance structure is so complicated that you need a class diagram, you are probably in for pain... But class diagrams do their job for sure.
I find UML useful as post-coding documentation. After you figured out how things work, you UML diagram your code to help explain the complicated parts.
UML is also useful for talking with coworkers. As a 'sketch' don't try to get everything right, but coworkers often need to know what your plans are if they are to find work that won't conflict with your plan.
I think another UML post was talking about sketch 'masala' graphs (throw everything into a touchy feely graphic that really doesn't say much). Being absolutely vague and nontechnical is an advantage in some cases, but not useful to engineers. UML, for all of it's faults, is precisely defined. Every symbol means something.
If your inheritance structure is so complicated that you need a class diagram, you are probably in for pain... But class diagrams do their job for sure.
I find UML useful as post-coding documentation. After you figured out how things work, you UML diagram your code to help explain the complicated parts.
UML is also useful for talking with coworkers. As a 'sketch' don't try to get everything right, but coworkers often need to know what your plans are if they are to find work that won't conflict with your plan.
I think another UML post was talking about sketch 'masala' graphs (throw everything into a touchy feely graphic that really doesn't say much). Being absolutely vague and nontechnical is an advantage in some cases, but not useful to engineers. UML, for all of it's faults, is precisely defined. Every symbol means something.
I still handwavily use one concept of class diagrams, letting arrows point at something that it depends on, without caring about the style of arrow, for sure I don't draw dashed arrows. It doesn't even have to be classes, could be a function calling another function, or a library depending another.
In my view, Statecharts have been the most useful UML diagrams, since it is possible to represent complex behaviour in it, even more than Sequence Diagrams. Their unlimited nesting, and capability to "remember", etc makes them quite useful.
UML statecharts are based on the theory of Harel statecharts, which you might find interesting: http://www.inf.ed.ac.uk/teaching/courses/seoc/2005_2006/reso...
I love Harel statecharts. They are a useful formalism that maps easily to code for a wide range of practical solutions. The key innovation is embedded states.
That said, the formalism does not say much about error handling. This is where state machines can get really hairy, in much the same way that throw/catch gets nasty in any non-trivial system.
That said, the formalism does not say much about error handling. This is where state machines can get really hairy, in much the same way that throw/catch gets nasty in any non-trivial system.
Sequence diagrams, as probably most other UML diagrams too, predate UML.
The point of UML was never to "invent" new diagrams. The point was to unify all diagrams so that your arrows in one visual-language are compatible with the arrows in another visual-language.
> Sequence diagrams, as probably most other UML diagrams too, predate UML.
This misses the point of UML, entirely. The point is not that diagramming was invented, it was that it was standardized.
So you don't have to spend half your meeting discussing just exactly what this particular arrow between these two boxes means.
This misses the point of UML, entirely. The point is not that diagramming was invented, it was that it was standardized.
So you don't have to spend half your meeting discussing just exactly what this particular arrow between these two boxes means.
Apparently it postdates UML too: there's a sequence diagram tool trending on the front page right now[1].
[1] https://news.ycombinator.com/item?id=26956728
[1] https://news.ycombinator.com/item?id=26956728
I think there's only one kind of diagram that in UML that doesn't have a clear predecessor: the activity diagram. There's a reason it's called the Unified Modelling Language, after all.
> UML, for all of it's faults, is precisely defined. Every symbol means something.
That's another fault, in my opinion. I'd rather have a vague high-level diagram with a write-up that rigorously describes all the invariants and structure than have a really semantic diagram which is meant to stand alone.
I think software structure is too complex to model with anything less powerful than natural language — that's why we add comments into code to explain the things that even the code itself doesn't make obvious.
That's another fault, in my opinion. I'd rather have a vague high-level diagram with a write-up that rigorously describes all the invariants and structure than have a really semantic diagram which is meant to stand alone.
I think software structure is too complex to model with anything less powerful than natural language — that's why we add comments into code to explain the things that even the code itself doesn't make obvious.
Yeah, sequence diagrams are the only ones I really like. Sometimes I auto-generate a UML class diagram from my code for a slide but I always have to trim out excess stuff I'm not interested in and usually add some annotations to make it say what I want.
I mean, over my career,
I’ve seen plenty of flow charts, sequence diagrams, boxes-connected-by-arrows drawings and such. I’ve yet to encounter anybody whose actually done a formal “by the book” UML diagram.
They are just too formal for real world use. Auto generated ones provide both too much information and too little information to be useful. I’ve never encountered human generated ones. Probably because they too rigid.
Maybe the problem with UML is it just didn’t solve any real world problem. Perhaps diagrams created by humans to be consumed by humans don’t need a formal spec. There is just too much variation to capture in such a spec.
At least I think. Again, I’ve ever encountered a by the book UML diagram in my entire career. I’ve encountered plenty of informal diagrams though.
They are just too formal for real world use. Auto generated ones provide both too much information and too little information to be useful. I’ve never encountered human generated ones. Probably because they too rigid.
Maybe the problem with UML is it just didn’t solve any real world problem. Perhaps diagrams created by humans to be consumed by humans don’t need a formal spec. There is just too much variation to capture in such a spec.
At least I think. Again, I’ve ever encountered a by the book UML diagram in my entire career. I’ve encountered plenty of informal diagrams though.
I spent quite a bit of time in corporate America in the early 2000's and saw a lot of UML being thrown around. I don't think anyone actually used any of the diagrams, but they were certainly required by the "process".
Fun fact, one guy on the team built hundreds of pages of documentation (mostly automated) including UML diagrams. We usually only used 1 or 2 pages of it downstream. He was famous for giving time back to the project. Come to think of it, maybe building in buffers in the project was his role the entire time and I just didn't realize it.
Fun fact, one guy on the team built hundreds of pages of documentation (mostly automated) including UML diagrams. We usually only used 1 or 2 pages of it downstream. He was famous for giving time back to the project. Come to think of it, maybe building in buffers in the project was his role the entire time and I just didn't realize it.
CASE never met its goals. It was yet another silver bullet in the software industry that has been ongoing since the IBM 360.
People point at NASA's software engineering as the gold standard, but what NASA shows is something that Charles Eames said "Design is about constraints".
NASA's software environments are all about constraints. Mission constraints, hardware constraints, environmental constraints, all lead to software that is beautifully written and maintained within those constraints.
The rest of the software world has tried to reproduce the process without understand the constraints. CASE, CMMI, Agile-with-a-capital-A, all are attempts by businesses to standardize and commoditize software development.
But software is about abstraction. We layer concepts on top of concrete hardware, then layer on top of that.
CASE didn't work because the layers were in the wrong places and of the wrong things. UML was an extension of that. It was based on expecting software development to be like engineering and manufacturing, which are oriented towards components and commodification, not layers.
People point at NASA's software engineering as the gold standard, but what NASA shows is something that Charles Eames said "Design is about constraints".
NASA's software environments are all about constraints. Mission constraints, hardware constraints, environmental constraints, all lead to software that is beautifully written and maintained within those constraints.
The rest of the software world has tried to reproduce the process without understand the constraints. CASE, CMMI, Agile-with-a-capital-A, all are attempts by businesses to standardize and commoditize software development.
But software is about abstraction. We layer concepts on top of concrete hardware, then layer on top of that.
CASE didn't work because the layers were in the wrong places and of the wrong things. UML was an extension of that. It was based on expecting software development to be like engineering and manufacturing, which are oriented towards components and commodification, not layers.
Back that truck up a bit.
CASE is a label for a set of tools that augment software development. Its not a "goal", it changes and morphs over time.
Every major computer and software house would develop something useful that would inevitably attempt to extend itself to control the entire software development life-cycle of activity. Even clients either pledged allegiance (vendor lock-in) or created their own Frankenstein SDLC mutations. All of this thrashing was used to insulate themselves from new or alternative ideas. And with the advent of personal computers all that stuff began a rapid entropy. All the "exclusive" iconic notations were in free fall.
And with that free fall, the realization that every diagram was tightly coupled to the next and that every neglected update to any diagram corrupted everything to follow - a big ball of systems design mud debt that was more cost effective to jettison than remedy. Couple that with the timely corporate reorganizations and layoffs and a perfect storm of costly obsolescence eliminated any taste to do that [UML-ish systems capture] again.
This never precluded the usefulness of subject diagramming at all but the costly CASE tool overhead simply evaporated except in low accountability government environments or deep pocket goliaths.
OTOH, CASE in an uncredited way still thrives in smart IDEs and Dev/Ops utilities that constrain the opportunity for non-conformant code to get deployed. Broader design issues remain.
CASE, in fact, did theoretically work. In practical, sustainable terms it could not.
The more accurate failure is in the attempt to create an iconic notation that could ever be broadly disseminated and practiced confidently in the eclectic and unpredictable programming community.
CASE is a label for a set of tools that augment software development. Its not a "goal", it changes and morphs over time.
Every major computer and software house would develop something useful that would inevitably attempt to extend itself to control the entire software development life-cycle of activity. Even clients either pledged allegiance (vendor lock-in) or created their own Frankenstein SDLC mutations. All of this thrashing was used to insulate themselves from new or alternative ideas. And with the advent of personal computers all that stuff began a rapid entropy. All the "exclusive" iconic notations were in free fall.
And with that free fall, the realization that every diagram was tightly coupled to the next and that every neglected update to any diagram corrupted everything to follow - a big ball of systems design mud debt that was more cost effective to jettison than remedy. Couple that with the timely corporate reorganizations and layoffs and a perfect storm of costly obsolescence eliminated any taste to do that [UML-ish systems capture] again.
This never precluded the usefulness of subject diagramming at all but the costly CASE tool overhead simply evaporated except in low accountability government environments or deep pocket goliaths.
OTOH, CASE in an uncredited way still thrives in smart IDEs and Dev/Ops utilities that constrain the opportunity for non-conformant code to get deployed. Broader design issues remain.
CASE, in fact, did theoretically work. In practical, sustainable terms it could not.
The more accurate failure is in the attempt to create an iconic notation that could ever be broadly disseminated and practiced confidently in the eclectic and unpredictable programming community.
Which is why sketch UML is popular. It looks like UML if you squint and gets the important reasons to use UML on a whiteboard. Then after everyone agrees you erase the whiteboard.
Before you erase, you always take a snapshot.
Sure, but you also take notes of the features, constraints, and invariants that were discussed. At the end of the meeting, instead of having a diagram which acts as a rigid spec, you have a set of notes and diagrams which informally describe the problem space, the proposed solutions, the benefits, the drawbacks, and any important details. And that's more useful and more flexible than UML.
Many do, but I find it a waste of time. The purpose is the shared discussion. Whatever the results are will be obsolete in a week.
> "Design is about constraints".
Indeed. I think most engineers would LOVE to have the kinds of constraints on their software that NASA has. The reason our code trends toward big balls of mud is that the requirements are ill-defined and constantly changing.
Indeed. I think most engineers would LOVE to have the kinds of constraints on their software that NASA has. The reason our code trends toward big balls of mud is that the requirements are ill-defined and constantly changing.
Welcome to the real world. As you point out, NASA lives in Wonderland by comparison. Good software handles real-world issues and changes without continual fundamental architectural redesigns. 95% of the bad software I've seen has been a result of not understanding one of two things, (which are really the same): 1) What the software needs to do to function in the real world, and 2) what the people who use the software need to do and how they think about their environment and the problems they need solved. It sounds trite, but in almost all cases, this really is all that separates great software from unbearably horrible software, and the astute observer will note that this has far more to do with understanding people than it does computers....
I don't disagree with you, but I don't think the responsibility lies primarily with the engineer. Especially in large orgs, you have armies of people whose job is ostensibly to understand the needs of the people their team serves, yet they continually fail to do so.
I'd argue as well that type systems in the extremely popular programming languages make it difficult to reduce the surface area of your problem appropriately as well.
Some more fringe languages make significant strides in this with dependent types.
The burden is much higher on tests than it needs to be because we can't express these constraints in code well enough.
Some more fringe languages make significant strides in this with dependent types.
The burden is much higher on tests than it needs to be because we can't express these constraints in code well enough.
Which dependently-typed languages have you found most productive?
Arguably components are layers of sorts, but in hardware layers are expensive, in software layers are cheap.
The constraints and costs are mostly around the long term maintaince rather than manufacturing. I think if compiling and distributing software had some meaningful cost associated with it software would be very different.
The constraints and costs are mostly around the long term maintaince rather than manufacturing. I think if compiling and distributing software had some meaningful cost associated with it software would be very different.
I worked for a company that was making a large CASE tool way back when and even at the time it felt like nonsense.
Internally it never even crossed our minds to use it as a means of building the tools themselves. I remember bringing this up at one point during a company meeting and the CEO glowered at me like I was pointing out some inconstancy in religious theology. He spun some web of garbage about why it wasn't appropriate for our specific needs. I was young and realized only afterward that it was just not something you were supposed to mention there.
It was actually fun to work on for a while and we sold a lot of product, but it eventually dried up along with the rest of that part of the industry.
Internally it never even crossed our minds to use it as a means of building the tools themselves. I remember bringing this up at one point during a company meeting and the CEO glowered at me like I was pointing out some inconstancy in religious theology. He spun some web of garbage about why it wasn't appropriate for our specific needs. I was young and realized only afterward that it was just not something you were supposed to mention there.
It was actually fun to work on for a while and we sold a lot of product, but it eventually dried up along with the rest of that part of the industry.
I had similar experience at a Semantic Web startup.
> I was young and realized only afterward...
If I could give young me any single piece of advice, it'd be "OMG STFU. Just smile and cash the check."
> I was young and realized only afterward...
If I could give young me any single piece of advice, it'd be "OMG STFU. Just smile and cash the check."
I'm curious how it relates to your startup. None of your data lived in a semantic db?
You'd've thought so. Persisted to SQL-Server. Early 2000s, so totally impractical.
The CTO cofounder was not impressed by the UI guy asking out loud what every one was thinking.
The fancy pants UI I was tasked to create wasn't even backed by a query language or path expressions. So dumb.
I stayed just long enough to find another gig.
PS- I did storyboard and wireframed a novel UI which resolved the graph visualization "paradox" (aka "focus+context"). It'd be perfect for neo4j & Cypher. I always thought I'd eventually circle back, if only to see if the idea had legs. Oh well.
The CTO cofounder was not impressed by the UI guy asking out loud what every one was thinking.
The fancy pants UI I was tasked to create wasn't even backed by a query language or path expressions. So dumb.
I stayed just long enough to find another gig.
PS- I did storyboard and wireframed a novel UI which resolved the graph visualization "paradox" (aka "focus+context"). It'd be perfect for neo4j & Cypher. I always thought I'd eventually circle back, if only to see if the idea had legs. Oh well.
I worked on a number of CASE tools and worked with them. You will NEVER see any diagrams describing the tools or how they were built.
Eating one's own dog food was not part of the road map.
Eating one's own dog food was not part of the road map.
> Internally it never even crossed our minds to use it as a means of building the tools themselves
Obviously, this doesn't apply to everything, but that's definitely a smell for product-market fit.
Obviously, this doesn't apply to everything, but that's definitely a smell for product-market fit.
Some IBMers told me they never used any rational modeling technique for any software.
I wonder if this was the case everywhere in the company.
I wonder if this was the case everywhere in the company.
Ha-ha, just now I am sitting writing documentation and use UML for illustrations. No-one told me it's dead.
I must say, the drawing (CASE) tools have always been missing even very basic elements of UML.
I learned UML in the year 2000 by reading the full "The Unified Modeling Language User Guide" book by Booch, Rumbaugh and Jacobson.
Every time I tried to create a diagram during the years, after envisioning how I would express the idea with UML I was blocked by the tool not supporting the notation elements I needed. Like for communication diagram the tool did not support the iteration notation for message numbers, only simple numbers (what tool was it? maybe even Rational Rose). Or qualified assignation (when association is a lookup by a key).
I adjusted to not expect much from the tools and I think I know how to use UML to create useful illustrations - just workaround the tool limitation with a comment or build the notation element from basic boxes or use a less descriptive notation then I wanted initially.
Not to say I used UML very much over the years, as I use it today I realize I forgot many things and need to refresh my memory.
However, I see sequence diagrams used all the time. From time to time I see other diagrams. The tools like plantuml as well as the online utilities like https://www.websequencediagrams.com/, https://swimlanes.io and https://sequencediagram.org are flourishing.
I must say, the drawing (CASE) tools have always been missing even very basic elements of UML.
I learned UML in the year 2000 by reading the full "The Unified Modeling Language User Guide" book by Booch, Rumbaugh and Jacobson.
Every time I tried to create a diagram during the years, after envisioning how I would express the idea with UML I was blocked by the tool not supporting the notation elements I needed. Like for communication diagram the tool did not support the iteration notation for message numbers, only simple numbers (what tool was it? maybe even Rational Rose). Or qualified assignation (when association is a lookup by a key).
I adjusted to not expect much from the tools and I think I know how to use UML to create useful illustrations - just workaround the tool limitation with a comment or build the notation element from basic boxes or use a less descriptive notation then I wanted initially.
Not to say I used UML very much over the years, as I use it today I realize I forgot many things and need to refresh my memory.
However, I see sequence diagrams used all the time. From time to time I see other diagrams. The tools like plantuml as well as the online utilities like https://www.websequencediagrams.com/, https://swimlanes.io and https://sequencediagram.org are flourishing.
UML is still taught in universities here in france. It's like the mafia of abstraction-oriented, ivory tower developer who just explain the software but never write code.
I guess one upside is that developers know how to make diagrams. Which is good.
I guess one upside is that developers know how to make diagrams. Which is good.
I was taught "UML" at university (UK, 10 years ago). I say "UML" because while that was the name given, we probably only had a few hours on it in my entire degree, and it was essentially boxes and arrows, with class names and methods, and the basics of sequence diagrams.
I think it was valuable. I suspect many engineers use simple diagrams in notebooks on a regular basis, and by introducing it very early in the degree it gave us another tool to help think about the code we were writing.
It wasn't actually UML, but I think it's a good thing to cover at the beginning of a course.
I think it was valuable. I suspect many engineers use simple diagrams in notebooks on a regular basis, and by introducing it very early in the degree it gave us another tool to help think about the code we were writing.
It wasn't actually UML, but I think it's a good thing to cover at the beginning of a course.
UML is totally useless abstraction and all until you somehow need to explain your architecture to 30+ developers/architects on the call.
"architecture"?
A simple diagram with components and how they communicate is pretty explanatory if you want a bird's eye view.
UML seems to try to be too specific and detailed when it comes to relationships, inheritances, hierarchies, etc but it's often just unnecessary, because every language/API/framework have their own way of dealing with details.
Not to mention that UML is often poorly specified and developers will not really respect the UML spec. It's like math, there are dialects. Programming language are better just because they have a proper parser that will verify correctness.
It's hard to understand why one would verify the correctness of an UML diagram.
A simple diagram with components and how they communicate is pretty explanatory if you want a bird's eye view.
UML seems to try to be too specific and detailed when it comes to relationships, inheritances, hierarchies, etc but it's often just unnecessary, because every language/API/framework have their own way of dealing with details.
Not to mention that UML is often poorly specified and developers will not really respect the UML spec. It's like math, there are dialects. Programming language are better just because they have a proper parser that will verify correctness.
It's hard to understand why one would verify the correctness of an UML diagram.
It does not have to be fully correct UML diagram.
But knowing the difference and being able to draw more or less accurate high-level sequence/flow/component diagram is vital skill for skilled developer.
>> Programming language are better just because Programming language is usually poor choice for explaining design of system
But knowing the difference and being able to draw more or less accurate high-level sequence/flow/component diagram is vital skill for skilled developer.
>> Programming language are better just because Programming language is usually poor choice for explaining design of system
It's not a bad thing to teach. Between "box diagrams" and "box diagrams with well-defined arrow types" I'd pick the later.
Same thing with design patterns: they won't solve all your problems but give engineers a common vocabulary.
Same thing with design patterns: they won't solve all your problems but give engineers a common vocabulary.
> programmers use “die” to mean “decline in relative marketshare”, not absolute marketshare. Lots of thot leaders bemoan how few devs understand really low-level systems anymore, but there are more kernel hackers in total than there were 30 years ago. They’re just a lower percentage of all developers.
This is such a great point!
This is such a great point!
UML is dying though. I remember being grilled during job interviews on OOP design questions with UML and all those obscure details. I hate it. But now even the embedded world is more about API contracts with system designs and data stores.
Very informal boxes and arrows with random annotations have proven far more effective than a fully specified visual language.
Very informal boxes and arrows with random annotations have proven far more effective than a fully specified visual language.
Yeah. API contracts are real (and sometimes even formalized to one or another degree with TLA+, IDLs like WSDL, and various other tools); UML was a fraud: https://news.ycombinator.com/item?id=26959307
Wait, "thot leaders"? Lol, I don't think that means what OP thinks it means.
If that was a quote it seems to have been edited. Anyway it seems to be a common spelling among a few people I met in Singapore, maybe due to this (now renamed) chain, or maybe the spelling preceded it.
https://www.asiaone.com/digital/after-years-online-ridicule-...
https://www.asiaone.com/digital/after-years-online-ridicule-...
…Goddamn it. I guess I'm an old now.
EDIT: Turns out it was not intentional, see below, now fixed on the post.
(original): Given how well-written the rest of the article is, I have to believe that's deliberate.
(original): Given how well-written the rest of the article is, I have to believe that's deliberate.
Plenty of English spelling simply doesn't make sense, "thought" is a good example of that. I'm ambivalent on vigilante spelling reforms, will have to think about it more. :-D
Typoing "thought leader" as a way to poke fun at them was deliberate, typoing it in a way that's also slang for a prostitute was completely unintentional and something I wouldn't have done if I knew. Changed it to something else for that reason.
I always thought it was slang for a woman who wasn't ashamed of her own sexuality, but of course people (not you specifically) would manage to turn that into a pejorative :/
I propose we use that as a term for what are today called Instagram influencers.
It's cost/benefit as far as kernel hackers vs. low-level systems devs. To get a job writing at a kernel level at a commercial company, you need what? A masters degree, at least, plus experience? Minimum, to even be considered. A decent dev job, you bang it out using a high level language and move into a management position and are making more than that kernel dev position, anyways.
That "hacker" who has studied the kernel, knows that if you can compromise the kernel and gain root, all the other programs fall because your password keychain will be exposed, and no one keeps track of their own passwords anymore. Hackers don't need a resume or interview and references as a barrier for entry, it's a skills test.
I sound like I'm romanticizing the "hacker", but I wouldn't want to be one. If you get caught, these days, you're hosed. Not to mention, a lot of them are state sponsored from not very nice states, so to speak.
That "hacker" who has studied the kernel, knows that if you can compromise the kernel and gain root, all the other programs fall because your password keychain will be exposed, and no one keeps track of their own passwords anymore. Hackers don't need a resume or interview and references as a barrier for entry, it's a skills test.
I sound like I'm romanticizing the "hacker", but I wouldn't want to be one. If you get caught, these days, you're hosed. Not to mention, a lot of them are state sponsored from not very nice states, so to speak.
This is anecdotal evidence but I think this is not an isolated story.
In 2001 I was working as real-time/embedded software engineer in France, our project was still running on old hardware, mostly C and asm on 68k.
One day before the summer vacations we were asked to come and see a full-day presentation of the future.
The presentation was made by an other team, working with embedded Java for microchips and ATM, UML and Rational was at the center of everything.
It was so unreal I had a hard time staying calm.
It was the day I decided to switch career, and that I would quit on the spot if they forced us to use anything as awful as those "methods".
In 2001 I was working as real-time/embedded software engineer in France, our project was still running on old hardware, mostly C and asm on 68k.
One day before the summer vacations we were asked to come and see a full-day presentation of the future.
The presentation was made by an other team, working with embedded Java for microchips and ATM, UML and Rational was at the center of everything.
It was so unreal I had a hard time staying calm.
It was the day I decided to switch career, and that I would quit on the spot if they forced us to use anything as awful as those "methods".
If UML is useful at all, it is maybe in enterprise software / modelling business processes and even then I had hard time justifying it, so I can completely understand your reaction when it comes to real-time/embedded software.
One point that a lot of these articles seem to gloss over, even in their discussions of changing software engineering culture, is that UML - used as a formal specification cast nearly in stone by a software architect - emerges from a time when the software architect was not very involved in the software implementation, which was done by programmers who received the specification. In this stratified approach, the specification had to be highly formalized and specific, since the architect had little role in the implementation - hence approaches like UML.
For many good reasons, including the rise of bottom-up hacker and startup culture, and the need for flexibility/iteration between the design and implementation, we've shifted to a paradigm where the architect is also usually the programmer, especially at the early stages of the software creation process. The architect themselves usually writes the core functionality of the software. This is true even at big modern tech companies.
Furthermore, "Software architect" is far less a distinct job description like it used to be, but now refers to the degree of responsibility an individual has for the software's structure and design, which usually correlated with experience and the project scope.
For many good reasons, including the rise of bottom-up hacker and startup culture, and the need for flexibility/iteration between the design and implementation, we've shifted to a paradigm where the architect is also usually the programmer, especially at the early stages of the software creation process. The architect themselves usually writes the core functionality of the software. This is true even at big modern tech companies.
Furthermore, "Software architect" is far less a distinct job description like it used to be, but now refers to the degree of responsibility an individual has for the software's structure and design, which usually correlated with experience and the project scope.
The Architect-Programmer model was also meant for offshoring.
It backfired horribly once "Architects" realized how precise they had to be with these cheap teams.
It backfired horribly once "Architects" realized how precise they had to be with these cheap teams.
> The Architect-Programmer model was also meant for offshoring.
I don't think this is true. The Architect-Programmer model precedes offshoring by decades, even if it was repurposed to facilitate offshoring.
It was the dominant model during the "Corporate IT" phase of the software industry (before the web/Internet took over), and was famously satirized in the classic movie Office Space and also in the Dilbert comics.
It has older roots in traditional corporate structures that strongly delineate "corporate" vs everyone else. The word "corporate" in office culture even used to mean "distant, out of touch bosses in luxury offices", and still kind of means that in industries with similarly stratified workforces.
I don't think this is true. The Architect-Programmer model precedes offshoring by decades, even if it was repurposed to facilitate offshoring.
It was the dominant model during the "Corporate IT" phase of the software industry (before the web/Internet took over), and was famously satirized in the classic movie Office Space and also in the Dilbert comics.
It has older roots in traditional corporate structures that strongly delineate "corporate" vs everyone else. The word "corporate" in office culture even used to mean "distant, out of touch bosses in luxury offices", and still kind of means that in industries with similarly stratified workforces.
'Culture Shifts' is the relevant bit. Orgs that realize a month's worth of planning to save a week's worth of dev work have realized UML isn't useful to them. Orgs that haven't don't think it goes far enough.
Let's not confuse the basic notation with the tooling and priesthood that grew up alongside it. Much like "Agile" there's still value in the small.
Hashing out a class diagram that shows how the domain entities relate to each other can still be pivotal in communicating the intended information model in a design. Pre-pandemic, this would involve words, lines, and cardinalities on a whiteboard (boxes optional).
Nowadays, a quick domain entity diagram in Whimsical does the trick.
A sequence diagram can quickly communicate an expected interaction pattern. The point is not to specify anything up front. The point of UML was always to serve first as a communication tool. Have commonly understood pictorial notations that let you talk about the software you're building.
When it was first invented, UML was aimed at "Unifying" how we diagram things. First, for books, and for the patterns movement. Even the heavy-weight Rational Unified Process was intended to be used in an iterative fashion. But it was constructed from a consulting mindset where you have intermediate steps of review and approval.
Blaming UML for the heavy-handed process where "thou shalt specify everything in advance" is like blaming the English language for that crappy novel you wasted your time on.
UML still has a place, IMHO, but only in that it helps you get over a few speed bumps on the way to helping your team produce working software.
Hashing out a class diagram that shows how the domain entities relate to each other can still be pivotal in communicating the intended information model in a design. Pre-pandemic, this would involve words, lines, and cardinalities on a whiteboard (boxes optional).
Nowadays, a quick domain entity diagram in Whimsical does the trick.
A sequence diagram can quickly communicate an expected interaction pattern. The point is not to specify anything up front. The point of UML was always to serve first as a communication tool. Have commonly understood pictorial notations that let you talk about the software you're building.
When it was first invented, UML was aimed at "Unifying" how we diagram things. First, for books, and for the patterns movement. Even the heavy-weight Rational Unified Process was intended to be used in an iterative fashion. But it was constructed from a consulting mindset where you have intermediate steps of review and approval.
Blaming UML for the heavy-handed process where "thou shalt specify everything in advance" is like blaming the English language for that crappy novel you wasted your time on.
UML still has a place, IMHO, but only in that it helps you get over a few speed bumps on the way to helping your team produce working software.
> When it was first invented, UML was aimed at "Unifying" how we diagram things.
See but “unifying how we diagram things” isn’t a problem that needs to be solved. A good diagram on a whiteboard is more art than science. It is also something that is intentionally as low of fidelity as possible because you might blow it away and do something entirely different.
There doesn’t need any “standard” for how to do adhoc diagrams.
The minute you add “formal standard” to the process it gets slower when you want it to be even faster. If my whiteboard diagram had to adhere to UML... I wouldn’t bother.
See but “unifying how we diagram things” isn’t a problem that needs to be solved. A good diagram on a whiteboard is more art than science. It is also something that is intentionally as low of fidelity as possible because you might blow it away and do something entirely different.
There doesn’t need any “standard” for how to do adhoc diagrams.
The minute you add “formal standard” to the process it gets slower when you want it to be even faster. If my whiteboard diagram had to adhere to UML... I wouldn’t bother.
It actually was a problem.
From the article:
> In his book on Business Object Notation, Bertrand Meyer lists twenty-six competing methods. I remember reading documents that listed over fifty, but I can’t seem to find them again so it might be a false memory.
I also distinctly remember how difficult it was to learn from other's designs. Back then, there was no Stack Overflow or Google. Developers like me obsessed over the latest books (like this new Design Patterns book, have you heard about it?!?)
It isn't a problem today because that's not how design ideas get communicated anymore. You have blog posts, and GitHub repos with examples and Markdown. This is better. But in the mid to late 90s, UML really helped.
Disclaimer: I was on many of those OMG committees for Model Driven Architecture and UML back in its heyday. I've also sat in Sushi restaurants after conference proceedings during dinner with some of the people mentioned in the article. The talk was of how we were going to change the industry. I smile to think of how things moved on without our dreams. :)
From the article:
> In his book on Business Object Notation, Bertrand Meyer lists twenty-six competing methods. I remember reading documents that listed over fifty, but I can’t seem to find them again so it might be a false memory.
I also distinctly remember how difficult it was to learn from other's designs. Back then, there was no Stack Overflow or Google. Developers like me obsessed over the latest books (like this new Design Patterns book, have you heard about it?!?)
It isn't a problem today because that's not how design ideas get communicated anymore. You have blog posts, and GitHub repos with examples and Markdown. This is better. But in the mid to late 90s, UML really helped.
Disclaimer: I was on many of those OMG committees for Model Driven Architecture and UML back in its heyday. I've also sat in Sushi restaurants after conference proceedings during dinner with some of the people mentioned in the article. The talk was of how we were going to change the industry. I smile to think of how things moved on without our dreams. :)
I don't see why UML diagrams wouldn't be very useful inside blog posts ?
> There doesn’t need any “standard” for how to do adhoc diagrams.
Oh yes there does.
I have seen people makeup ad hoc notation during an ad hoc diagram and then get confused by what it means orthe meaning shifts during the diagram. No, we have a standardised language. You wouldn't want blueprints with ad hoc units. "14 snails thick, and 3 rabbit-seconds in length which we indicate with an underlined star"
Oh yes there does.
I have seen people makeup ad hoc notation during an ad hoc diagram and then get confused by what it means orthe meaning shifts during the diagram. No, we have a standardised language. You wouldn't want blueprints with ad hoc units. "14 snails thick, and 3 rabbit-seconds in length which we indicate with an underlined star"
You don't need a standard for ad-hoc whiteboard diagrams or expositional figures. You're comparing apples and oranges because what you are talking about needing this level of precision in is more "blueprints", not ad-hoc diagrams.
And, while it's my opinion only, blueprints for software are best written in prose. For C++ for example, I think the best language to use is concise, precise, well written, C++. And so on.
And, while it's my opinion only, blueprints for software are best written in prose. For C++ for example, I think the best language to use is concise, precise, well written, C++. And so on.
Just to point out - you've listed two diagram types. There are 14.
Of those two (which are the only two I've heard called out by their name in any business context), I've not seen consistent notation. Sometimes it's a problem, sometimes it isn't, but invariably what is more important is the conversation happening alongside the diagram; the diagram by itself is not a useful artifact, just like the slides to a (good) presentation, by themselves, are not useful.
Of those two (which are the only two I've heard called out by their name in any business context), I've not seen consistent notation. Sometimes it's a problem, sometimes it isn't, but invariably what is more important is the conversation happening alongside the diagram; the diagram by itself is not a useful artifact, just like the slides to a (good) presentation, by themselves, are not useful.
Component diagrams, state charts, and activity diagrams also still appear in some of my whiteboard sketches. They are useful in specific contexts, but we use them far less often.
The last time I drew a use case diagram, it was in jest.
The last time I drew a use case diagram, it was in jest.
So most if not all of UML's diagrams can show up in -some- form when conveying information. Just, no one remembers the UML, and certainly no one thinks "Ah-hah. A (diagram type) would be useful here. I shall draw one in accordance with all outlined UML conventions".
No, but when I'm drawing diagrams and realize I need to show that this relationship is different to that one, I think "Ah-hah. I will use the UML arrow notation instead of inventing something incoherent as I go".
[deleted]
I'm not going to defend UML, but it's disappointing to skim the recent walls of UML headlines and comments on HN, and assume that these posts are going to determine what most HN people think about UML, modeling, CASE, etc.
(This assumption I think is sorta analogous to how we knew waterfall and even spiral were hard, and that many teams would need help to deliver successfully... then someone told those teams they don't have to work that hard, if they instead operated more like situated action reactive agents instead of planning ones... and then the default impression became that people who did waterfall/spiral must not have been as enlightened as ourselves, and we have nothing to learn from them. :)
I could yammer for hours on methods and tools, but I'm more passionate about other topics right now. I'll just quickly point out one barrier to uptake of UML...
One of the barriers to the modeling methodologies was that many people didn't know how to use them, and so presumably didn't see benefit. That they didn't get it was obvious when you'd see diagrams that were simply wrong, or that expressed no information other than being a not-very-helpful transliteration of code. And a lot of the examples people saw also had this problem.
A memorable epiphany I had was shortly after joining an R&D group for next-gen OO CASE. One of the senior people was describing some complicated unfamiliar thing we had to understand, and using an OMT diagram to do so, pointing to things on the diagram as he explained... and it clicked: I was understanding so much from a diagram, and we couldn't have gotten that from code.
I then learned all the other modeling things, and set about to design an approach to make it practical to use them all sorts of places (roundtrip, methodology flexibility, better HCI, etc.). Then business things happened, maybe because Rational was locking in an industry shift with what was turning into UML, and so I instead went to work on Web and HCI&AI hybrids.
(This assumption I think is sorta analogous to how we knew waterfall and even spiral were hard, and that many teams would need help to deliver successfully... then someone told those teams they don't have to work that hard, if they instead operated more like situated action reactive agents instead of planning ones... and then the default impression became that people who did waterfall/spiral must not have been as enlightened as ourselves, and we have nothing to learn from them. :)
I could yammer for hours on methods and tools, but I'm more passionate about other topics right now. I'll just quickly point out one barrier to uptake of UML...
One of the barriers to the modeling methodologies was that many people didn't know how to use them, and so presumably didn't see benefit. That they didn't get it was obvious when you'd see diagrams that were simply wrong, or that expressed no information other than being a not-very-helpful transliteration of code. And a lot of the examples people saw also had this problem.
A memorable epiphany I had was shortly after joining an R&D group for next-gen OO CASE. One of the senior people was describing some complicated unfamiliar thing we had to understand, and using an OMT diagram to do so, pointing to things on the diagram as he explained... and it clicked: I was understanding so much from a diagram, and we couldn't have gotten that from code.
I then learned all the other modeling things, and set about to design an approach to make it practical to use them all sorts of places (roundtrip, methodology flexibility, better HCI, etc.). Then business things happened, maybe because Rational was locking in an industry shift with what was turning into UML, and so I instead went to work on Web and HCI&AI hybrids.
This is an understated truth about most iconic notations let alone anything instrumented into a CASE tool. That is that the Agile movement introduced a meanness and immediate gratification factor into the very idea that modeling software was useful or necessary. Concepts as simple as an input arrow going into a process would enter from the left of a circle or box and the output would exit from the right were the object of debate and ridicule.
Why bother? Skippy, the agile programmer, had already coded something up that happened to feature the end-users favorite color.
Eye candy always trumps rigor and deliberate modeling of components.
Formal notations didn't stand a chance.
Why bother? Skippy, the agile programmer, had already coded something up that happened to feature the end-users favorite color.
Eye candy always trumps rigor and deliberate modeling of components.
Formal notations didn't stand a chance.
We still use UML for illustrative documentation purposes leading the prose, sequence diagrams, state machines, activities. We barely ever use class diagrams. We don't draw, we let PlantUML do that. We only use UML because, well, PlantUML outputs those diagrams. If its output were non-UML sequence diagrams, state machines or activity diagrams, we'd be using that for documentation purposes.
That's why I whole-heartedly disagree with "At best you’ve got a cumbersome system that’s significantly worse than using a graphical editor" from the article. I'll take succinct text over your graphical editor any day of the week, and my colleagues agree with me.
Anyways. All hail plantuml ;)
That's why I whole-heartedly disagree with "At best you’ve got a cumbersome system that’s significantly worse than using a graphical editor" from the article. I'll take succinct text over your graphical editor any day of the week, and my colleagues agree with me.
Anyways. All hail plantuml ;)
Yep. UML is meh but state and sequence diagrams can be good.
Besides plantuml there's also the very similar mermaid which will work in gitlab markdown and show up in the browser.
Besides plantuml there's also the very similar mermaid which will work in gitlab markdown and show up in the browser.
Some of the resistance I have encountered from developers and engineering managers to writing sequence diagrams has been because it makes it harder for them to bullshit about what their code does, how it does it, and how complex (or not) it really is.
When you put an abstraction over something its parts can be replacable and in non-growth oriented development cultures this is what people try to avoid. Essentially, resistance to abstraction is often resistance to being managed.
When you put an abstraction over something its parts can be replacable and in non-growth oriented development cultures this is what people try to avoid. Essentially, resistance to abstraction is often resistance to being managed.
More charitably, sometimes it’s impossible to accurately sequence events until you’ve tried implementing a thing, especially so when a 3rd party is involved.
We use a vendor’s API that’s very well documented, and if you asked me to chart how we’d use it based on those docs, it would be very straightforward. In reality, we (only halfway) joke that this vendor puts the “eventual” in “eventual consistency”. Like no kidding, it’s often up to 5 minutes between PUTting an object and being able to GET it back. This doesn’t violate any of their API docs at all, but you tend to think of CRUD apps as being either synchronous or having latencies of a second or two. This vendor never claimed to have be that way but I kind of assumed it, which is 100% my fault but still a bit understandable I think.
So the actual sequence doc is much more complex with several stages of polling cycles. In fact, it's really a linearization of what's actually implemented as a state machine. If a PM had held me to a simple, linear sequence diagram, they'd be upset that what I delivered didn't look at all like what I'd promised, but that's because we didn't know everything important in advance and we didn't know that we didn't know that. Lessons learned, huh?
I don’t mind diagrams for documenting what was actually done so the next maintainer can understand why things are a certain ways. I would enormously resist being made to write code to satisfy them in most contexts.
We use a vendor’s API that’s very well documented, and if you asked me to chart how we’d use it based on those docs, it would be very straightforward. In reality, we (only halfway) joke that this vendor puts the “eventual” in “eventual consistency”. Like no kidding, it’s often up to 5 minutes between PUTting an object and being able to GET it back. This doesn’t violate any of their API docs at all, but you tend to think of CRUD apps as being either synchronous or having latencies of a second or two. This vendor never claimed to have be that way but I kind of assumed it, which is 100% my fault but still a bit understandable I think.
So the actual sequence doc is much more complex with several stages of polling cycles. In fact, it's really a linearization of what's actually implemented as a state machine. If a PM had held me to a simple, linear sequence diagram, they'd be upset that what I delivered didn't look at all like what I'd promised, but that's because we didn't know everything important in advance and we didn't know that we didn't know that. Lessons learned, huh?
I don’t mind diagrams for documenting what was actually done so the next maintainer can understand why things are a certain ways. I would enormously resist being made to write code to satisfy them in most contexts.
There are more charitable reasons, I agree.
However, the skill of being able to black-box a process is not distributed evenly. "Something goes in, something comes out" is simpler, and yet it requires a mental parallelism that we often don't realize can be more sophisticated than using domain knowledge to serially sound out individual concrete steps and conditions until you find a way to close the conceptual loop.
Architects and PM's take flak for not being technical enough because it's generally true that the map is not the territory. But having been there, it can be like watching engineers run a maze without a map, and refusing to either accept a map of the maze, or share a map with anyone else.
It's BFS vs. DFS, and they are approapriate for different types of problems. UML in totality is not always helpful, but the most powerful aspects of it can be disruptive to team anti-patterns, and I think this is part of why it has lost a lot of traction.
However, the skill of being able to black-box a process is not distributed evenly. "Something goes in, something comes out" is simpler, and yet it requires a mental parallelism that we often don't realize can be more sophisticated than using domain knowledge to serially sound out individual concrete steps and conditions until you find a way to close the conceptual loop.
Architects and PM's take flak for not being technical enough because it's generally true that the map is not the territory. But having been there, it can be like watching engineers run a maze without a map, and refusing to either accept a map of the maze, or share a map with anyone else.
It's BFS vs. DFS, and they are approapriate for different types of problems. UML in totality is not always helpful, but the most powerful aspects of it can be disruptive to team anti-patterns, and I think this is part of why it has lost a lot of traction.
> We use a vendor’s API that’s very well documented, and if you asked me to chart how we’d use it based on those docs, it would be very straightforward. In reality, we (only halfway) joke that this vendor puts the “eventual” in “eventual consistency”. Like no kidding, it’s often up to 5 minutes between PUTting an object and being able to GET it back. This doesn’t violate any of their API docs at all, but you tend to think of CRUD apps as being either synchronous or having latencies of a second or two. This vendor never claimed to have be that way but I kind of assumed it, which is 100% my fault but still a bit understandable I think.
Funnily enough, dealing with a similar vendor is how I got my start with formal methods. Except in addition to 5+ minute latencies, if you sent a second PUT request during that time they _would start randomly deleting data._ Good times, good times.
Funnily enough, dealing with a similar vendor is how I got my start with formal methods. Except in addition to 5+ minute latencies, if you sent a second PUT request during that time they _would start randomly deleting data._ Good times, good times.
Shudder.
This one triggered conversations along the lines of “how hard would it be to replace that vendor with a Django app, really?”
This one triggered conversations along the lines of “how hard would it be to replace that vendor with a Django app, really?”
> it’s impossible to accurately sequence events until you’ve tried implementing a thing
In a general sense it's impossible to accurately model a thing until you've implemented it. All models wrong. Some models are useful. But doing the modelling, in the form of creating a sequence diagram, can be part of the process of going from idea to working code.
In a general sense it's impossible to accurately model a thing until you've implemented it. All models wrong. Some models are useful. But doing the modelling, in the form of creating a sequence diagram, can be part of the process of going from idea to working code.
Managers like knowing what the code will do. The trouble is, compilers also like knowing what the code will do, and as soon as they know, it's time for delivery, and delaying while the boss catches up doesn't seem acceptable. How can managers find out what the code does ahead of delivery? There's only one way: managers have to ask to see the code before the compiler does.
Until we get some kind of lid on complexity, I don't think real engineering will happen.
If any abstract box in your diagram can be arbitrarily complex, then it's not going to stay in that little box. It will develop tendrils into logging and error mechanisms, and start to find extra jobs it can do with extra connections to other components. Pretty soon the semantics of the box will be so complex that they can't be reproduced elsewhere, and you will have to use that box for all kinds of new tasks.
I imagine a database was, at one time, just a little box on someone's diagram. Now it's Oracle Spanner RAC Mongo Hadoop and must be used by every line of code in the world to get anything done. That's why a diagram is useless (EDIT: useless as a prescriptive language, but still useful as a descriptive language.).
If any abstract box in your diagram can be arbitrarily complex, then it's not going to stay in that little box. It will develop tendrils into logging and error mechanisms, and start to find extra jobs it can do with extra connections to other components. Pretty soon the semantics of the box will be so complex that they can't be reproduced elsewhere, and you will have to use that box for all kinds of new tasks.
I imagine a database was, at one time, just a little box on someone's diagram. Now it's Oracle Spanner RAC Mongo Hadoop and must be used by every line of code in the world to get anything done. That's why a diagram is useless (EDIT: useless as a prescriptive language, but still useful as a descriptive language.).
I think UML died because it was never that useful in the first place. If you want a high level design to get an idea across, a back of the napkin sketch is a lot quicker and less formal, and once you start getting into the formalities of UML it suddenly becomes more effort than it's worth, since you need tooling etc. It also implies a heavy OO approach, which isn't really going to fly with C hackers or functional programming enthusiasts.
This discussion and the one it references, previously on HN[1] conflate UML the diagram syntax (which remains useful) with UML as visual CASE tool. The latter never really lived, any more than any other "programming without writing code!" tool lived.
The former is alive and well, after shedding a lot of the fiddly details and requirements that the bits of the diagram be expressed in low-level details. Case in point: association vs aggregation vs. composition in class diagrams. All three express a similar idea by having a line joining the two classes: this class and this other class work together. But for aggregation and composition, one end of the line is supposed to have a diamond. Which end? Should the diamond be open or closed? What about multiplicity? Which end of the line has the number? It depends, sometimes both.
But all that detail, while sometimes useful to people looking at the diagram, really only matters for the benighted folks who try to make their UML diagrams input into code generators.
Forget "UML is dying", accept that CASE tools will never be more than fancy and fiddly code generators, and use the general ideas around diagramming, including some UML syntax, as a way to communicate among team members and stakeholders who are sufficiently technical.
1. https://news.ycombinator.com/item?id=26934577
p.s. Don't use quotation marks for emphasis. Ever. It's wrong.
The former is alive and well, after shedding a lot of the fiddly details and requirements that the bits of the diagram be expressed in low-level details. Case in point: association vs aggregation vs. composition in class diagrams. All three express a similar idea by having a line joining the two classes: this class and this other class work together. But for aggregation and composition, one end of the line is supposed to have a diamond. Which end? Should the diamond be open or closed? What about multiplicity? Which end of the line has the number? It depends, sometimes both.
But all that detail, while sometimes useful to people looking at the diagram, really only matters for the benighted folks who try to make their UML diagrams input into code generators.
Forget "UML is dying", accept that CASE tools will never be more than fancy and fiddly code generators, and use the general ideas around diagramming, including some UML syntax, as a way to communicate among team members and stakeholders who are sufficiently technical.
1. https://news.ycombinator.com/item?id=26934577
p.s. Don't use quotation marks for emphasis. Ever. It's wrong.
I think there's an important distinction to be made as to the "goal" not of CASE tools but of iconic notation.
Iconic notations exist to describe all manner and form of reality and technical specification.
The first "goal" of UML was to eliminate and consolidate the free-range software development notations. And that was something that could have turned into something useful.
UML's attention turned to code generation and no-code paradigms that will take generations of refinement to ever be useful in complex environments. Diagramming notations were contorted to serve the goal of code generation instead of programmer utility.
The consequence was that programmers were denied anything personally useful about UML and instead were saddled with a soul-sucking, task master of a tool that never fulfilled the business community's no-code expectations. The kicker was that now the development staff needed to untangle the no-code, generated code to make it work. What's to like?
Iconic notations exist to describe all manner and form of reality and technical specification.
The first "goal" of UML was to eliminate and consolidate the free-range software development notations. And that was something that could have turned into something useful.
UML's attention turned to code generation and no-code paradigms that will take generations of refinement to ever be useful in complex environments. Diagramming notations were contorted to serve the goal of code generation instead of programmer utility.
The consequence was that programmers were denied anything personally useful about UML and instead were saddled with a soul-sucking, task master of a tool that never fulfilled the business community's no-code expectations. The kicker was that now the development staff needed to untangle the no-code, generated code to make it work. What's to like?
You've pinpointed what sent UML off the rails. CASE tools were going through one of their hype phases about the same time UML was getting attention. The CASE people latched on to UML as the notation that would enable automatic code generation and round-tripping, and that led to the contortions you mention.
We still have diagramming tools that create and work with the useful parts of UML in reasonable ways, we just needed to jettison the no-code weight that was dragging the notation into dead ends.
We still have diagramming tools that create and work with the useful parts of UML in reasonable ways, we just needed to jettison the no-code weight that was dragging the notation into dead ends.
I think the author addressed this?
> The other ambiguity is what we mean by UML. First of all, UML consists of over a dozen different diagram types. I still see people regularly use sequence diagrams. Second, there’s many different ways people use UML diagrams. Martin Fowler, a prominent figure in both the UML and Agile worlds, identifies three types of uses: sketching, blueprinting, and programming.
Then they talk explicitly about blueprinting.
> The other ambiguity is what we mean by UML. First of all, UML consists of over a dozen different diagram types. I still see people regularly use sequence diagrams. Second, there’s many different ways people use UML diagrams. Martin Fowler, a prominent figure in both the UML and Agile worlds, identifies three types of uses: sketching, blueprinting, and programming.
Then they talk explicitly about blueprinting.
Yup, and the only UML book I ever bought and used, UML Distilled, was written by Fowler and Kendall Scott. It's a slim book, and notably says little to nothing about UML as a CASE tool. There's definitely nothing about any specific program for generating code, and not much about generating diagrams from code, either.
> UML the diagram syntax (which remains useful)
It may be useful, but aside from sequence diagrams I rarely see anyone using it; its not just CASE that has died but the wider field of systematic analysis and modeling has declined in relative importance. Not having a good model of how it fits into short-iteration development workflows that eschew big upfront design seems to be the main cause.
And for what remains of that space, there are newer tools occupying some of it.
It may be useful, but aside from sequence diagrams I rarely see anyone using it; its not just CASE that has died but the wider field of systematic analysis and modeling has declined in relative importance. Not having a good model of how it fits into short-iteration development workflows that eschew big upfront design seems to be the main cause.
And for what remains of that space, there are newer tools occupying some of it.
I still use it, just a few minutes ago actually. If there's a process that goes over multiple threads or actors, it's nice to have a sequence (?, that one with lanes). If there's a process that has distinct ways to change states it's nice to make a state diagram. Also you might like to have a diagram about your database before you build your database. Or one of those classic decision trees that everybody uses even outside of software.
I use a database diagram before I do anything in a new project all the time myself. It's a good way to start thinking about any data-heavy project. Inevitably there will be things I didn't consider and have to add while implementing but it's still a great first step.
I'll even draw them on paper sometimes (it's just squares with types and column names inside and arrows pointing to keys on other tables, mostly).
I'll even draw them on paper sometimes (it's just squares with types and column names inside and arrows pointing to keys on other tables, mostly).
UML as "Language to depict diagrams + set of tools on top of it + unified process and all the waterfall-ish bureaucracy around it" - yeah, sure, it's dead in the sense barely anyone uses it in such form.
UML as "Language to depict diagrams" - not so sure, I use component, state and sequence diagrams all the time (in both interview and main job settings).
UML as "Language to depict diagrams" - not so sure, I use component, state and sequence diagrams all the time (in both interview and main job settings).
Hmmm. Not-so-fun memories of those times:
1. Doing sequence diagrams in Visio, sans any kind of plugin that understood them; cue realising you'd missed a bit out and having to do an awkward group-select and drag a load of gubbins down the page to make room, then finding you'd missed an arrow or something ....
2. CASE tools that promised round-trip engineering .... so my Hovercraft contains many Eels, and I have that in my nice UML diagram, but how is that going to translate into pre-generics Java and back again? Spoiler - it isn't
3. Being given a massive wad of UML diagrams by a client, but the author had actually done all the contains relations as if it was a data model diagram, so all the relations were backwards - i.e. Eel diamond-arrow Hovercraft, because that's how the foreign keys would be done. How to break this kindly ...
1. Doing sequence diagrams in Visio, sans any kind of plugin that understood them; cue realising you'd missed a bit out and having to do an awkward group-select and drag a load of gubbins down the page to make room, then finding you'd missed an arrow or something ....
2. CASE tools that promised round-trip engineering .... so my Hovercraft contains many Eels, and I have that in my nice UML diagram, but how is that going to translate into pre-generics Java and back again? Spoiler - it isn't
3. Being given a massive wad of UML diagrams by a client, but the author had actually done all the contains relations as if it was a data model diagram, so all the relations were backwards - i.e. Eel diamond-arrow Hovercraft, because that's how the foreign keys would be done. How to break this kindly ...
Bah, the only time I was asked to do an UML diagram I was at the university.
I ended up doing the coding, and using a tool that generated the UML from it, so that I could make it nicer.
> Code first, design later "they" said
Ah, ops... :)
I ended up doing the coding, and using a tool that generated the UML from it, so that I could make it nicer.
> Code first, design later "they" said
Ah, ops... :)
A nice list.
Personally, I've always thought that "too complex" was the most essential reason. To really get the intended value out of UML (as opposed to, say, cell phone pictures of ad-hoc whiteboard flowcharts), you need to put a lot of time into learning all its intricacies. Doing it right is a specialized skill, enough so that you probably need to commit a single person to maintaining the UML diagrams if you want things to remain coherent.
But that's a problem right there. Smaller teams can't afford to commit a person to fiddling with flowcharts like that, and, even on larger teams, the need to communicate with that person in order to make sure the charts stay up to date is a large effort. When I was at a Global 500 company, we had regular meetings with the UML folks where we'd go over the charts, they'd explain what everything meant - none of the developers had sufficient UML expertise to independently understand the diagrams beyond a rudimentary level - we'd explain where things had drifted away from the spec, and back and forth we'd go until it all settled out.
And I don't know what purpose all of that effort served, aside from satisfying a rule that had been passed down from above. Developers never went back and referred to these diagrams. Like I said, we couldn't really understand them, so it was quicker, easier, and more accurate to just read the code or talk to each other.
Managers were even less able to understand them, and knew that they were only accurate up to the last UML sync-up, which means they wouldn't cover work in progress, which is almost always the thing they're currently looking to understand. So they'd talk to developers. And maybe we'd have a meeting to bring each other to speed on how it all works and how that's working out, and how it needs to change. And maybe, during that meeting, we'd draw an ad-hoc diagram on the whiteboard while we talk. And maybe, if everyone thought it was sufficiently useful, we'd leave it up there and write "don't erase" next to it. And the fact that there was no formal specification of the visual language turned out not to matter, in the end, because the diagram never needed to be a formal specification in the first place; it was just a mnemonic device to help everyone remember what was discussed in the design meeting.
Personally, I've always thought that "too complex" was the most essential reason. To really get the intended value out of UML (as opposed to, say, cell phone pictures of ad-hoc whiteboard flowcharts), you need to put a lot of time into learning all its intricacies. Doing it right is a specialized skill, enough so that you probably need to commit a single person to maintaining the UML diagrams if you want things to remain coherent.
But that's a problem right there. Smaller teams can't afford to commit a person to fiddling with flowcharts like that, and, even on larger teams, the need to communicate with that person in order to make sure the charts stay up to date is a large effort. When I was at a Global 500 company, we had regular meetings with the UML folks where we'd go over the charts, they'd explain what everything meant - none of the developers had sufficient UML expertise to independently understand the diagrams beyond a rudimentary level - we'd explain where things had drifted away from the spec, and back and forth we'd go until it all settled out.
And I don't know what purpose all of that effort served, aside from satisfying a rule that had been passed down from above. Developers never went back and referred to these diagrams. Like I said, we couldn't really understand them, so it was quicker, easier, and more accurate to just read the code or talk to each other.
Managers were even less able to understand them, and knew that they were only accurate up to the last UML sync-up, which means they wouldn't cover work in progress, which is almost always the thing they're currently looking to understand. So they'd talk to developers. And maybe we'd have a meeting to bring each other to speed on how it all works and how that's working out, and how it needs to change. And maybe, during that meeting, we'd draw an ad-hoc diagram on the whiteboard while we talk. And maybe, if everyone thought it was sufficiently useful, we'd leave it up there and write "don't erase" next to it. And the fact that there was no formal specification of the visual language turned out not to matter, in the end, because the diagram never needed to be a formal specification in the first place; it was just a mnemonic device to help everyone remember what was discussed in the design meeting.
Be me, mid 90s. Wannabe methodologist. Earnest, enthusiastic. Dismissive of OOAD/P criticisms.
Attend OOPSLA '98. Spot break out session on Software Architecture. Featuring Grady Booch! Oh boy, I gotta go.
Finally work up courage to ask my hero Booch "What is 'Software Architecture'?"
Long, thoughtful pause. "'Software Architecture' is what Software Architects create."
Poof. Bubble popped.
FWIW, the Agile Methodology™ hype cycle is self same.
Attend OOPSLA '98. Spot break out session on Software Architecture. Featuring Grady Booch! Oh boy, I gotta go.
Finally work up courage to ask my hero Booch "What is 'Software Architecture'?"
Long, thoughtful pause. "'Software Architecture' is what Software Architects create."
Poof. Bubble popped.
FWIW, the Agile Methodology™ hype cycle is self same.
I've heard this definition of software architecture that I like: "the art of getting right up front the things that would be very hard to change latter if you got them wrong". What those things are is different for every project. They can even change over time, but you need to get them right up front anyway.
That totally works. Thanks.
Much later, I stumbled apon (paraphrasing) "architecture is the set of visible design choices" from the economics book Design Rules: The Power of Modularity.
I long thought that book would become seminal, classic. Shows what I know.
Much later, I stumbled apon (paraphrasing) "architecture is the set of visible design choices" from the economics book Design Rules: The Power of Modularity.
I long thought that book would become seminal, classic. Shows what I know.
My wife had to use IBM Rational Rose at her previous job. I have to say I'm glad I never had to deal with this kind of BS as a developer.
When was that? I remember evaluating it in the late nineties. I was fascinated by the idea of roundtripping UML-generated C++ code but it took so much effort to generate the code I wanted I gave up quickly.
Ugh, a year ago, they are probably still using it.
To defend UML a bit, I found sequence diagrams really useful when designing or understanding complex interactions in a software system.
You mean Message Sequence Charts? :) https://en.wikipedia.org/wiki/Message_sequence_chart
I still see UML as a blueprint in my industry (safety critical software), MagicDraw is one tool rising in prominence, Enterprise Architect is another. I definitely have seen a decline in UML for code generation. (I forget if the tools I mention have code generator capability but I generally don’t see them used if they do)
Interestingly I have seen a steady uptake in model driven development with code generation but it tends to be in tools like SCADE or Simulink, tools that are not directly object oriented but are more traditionally model oriented (code generation wise I believe these both generate C code).
I think one problem with UML as code generation is that the relationship between the model and the code can be constraining and many domain experts do not think in terms of classes and objects.
By the way, I do like the concept of UML as generating a code shell that gets filled in and modified, anyone have any open source recommendations for that? Preferably something that can integrate with Java and Spring
Interestingly I have seen a steady uptake in model driven development with code generation but it tends to be in tools like SCADE or Simulink, tools that are not directly object oriented but are more traditionally model oriented (code generation wise I believe these both generate C code).
I think one problem with UML as code generation is that the relationship between the model and the code can be constraining and many domain experts do not think in terms of classes and objects.
By the way, I do like the concept of UML as generating a code shell that gets filled in and modified, anyone have any open source recommendations for that? Preferably something that can integrate with Java and Spring
Safety critical software is about limiting the available software constructs to known safe ones (eg the MISRA standard) and adopting techniques and tooling like TLA+ that can be used to prove correct behavior.
Things like FMECA etc are techniques for safe software (and hardware).
Diagrams don't replace that. OOP as a technique (at least stuff about classes and inheritance and polymorphism) doesn't replace that.
OOP in terms of objects and messaging, with state machines are certainly part of safety software development.
The leftover CASE tools like Enterprise Architect are now basically documentation engines and have very little to do with the actual software development process.
Things like FMECA etc are techniques for safe software (and hardware).
Diagrams don't replace that. OOP as a technique (at least stuff about classes and inheritance and polymorphism) doesn't replace that.
OOP in terms of objects and messaging, with state machines are certainly part of safety software development.
The leftover CASE tools like Enterprise Architect are now basically documentation engines and have very little to do with the actual software development process.
> Traditional enterprises were the dominant software employers in the 1990’s, meaning that tech trends likely reflected their interests. That would be a good explanation for UML’s initial rise. Over the past two decades, though, software culture shifted progressively towards large tech-first companies and startups. Neither, historically, was the target audience of CASE vendors. Over time traditional enterprise starts borrowing from tech and startups vs the other way around, leading to the progressive decline of CASE in its extant niches.
This I think was the real thrust of the argument. While UML's death may be exaggerated in many corners of the corporate world, so too is its life in representing our industry as a whole.
This I think was the real thrust of the argument. While UML's death may be exaggerated in many corners of the corporate world, so too is its life in representing our industry as a whole.
I'm pretty sure UML and RUP were in the Gartner Magic Quadrant in the early 2000s.
I wonder if git had a part in it. That UML doesn't have a good textual format, or really any standard file format, means it really doesn't play well with git. I remember IBM/Rational had some kind of diff & merge tool for UML, but it was horrible.
It has a standard format, it's just unpleasant. (XMI is not for writing by hand.)
There were other textual serializations in the various OMG standards. But you're representing a graph, which never works properly with line-oriented merge tools.
There were other textual serializations in the various OMG standards. But you're representing a graph, which never works properly with line-oriented merge tools.
Plant UML was pretty widely used. The interface is very 2000 but it's still maintained.
Have you looked at PlantUML or WebSequenceDiagrams syntax?
This screams XML.
If you mean XMI that's XML indeed. But merely it using XML doesn't begin to describe its insanity. It has metamodels, meta-metamodels, ..., all described in OMG's "MOF", starting from the idea that OO principles somehow pass as formal method or logical framework, and ends in "Extreme UML", posing decision problems with unknown complexity/feasibility/decidability left and right.
It's truly junior OOP zealotry going beyond its comfort zone. What's particular bad IMHO is that OMG/IBM managed to undermine completely unrelated and useful BPM modelling standards into the dead end that was UML, taking those down along with the nonsensical XMI, MOF, EMF, GEF.
It's truly junior OOP zealotry going beyond its comfort zone. What's particular bad IMHO is that OMG/IBM managed to undermine completely unrelated and useful BPM modelling standards into the dead end that was UML, taking those down along with the nonsensical XMI, MOF, EMF, GEF.
My CS education was in the right timeframe, but somehow I have been able to evade the UML rabbit hole.
We did have a course on Object Oriented Databases, which would obviously take over the world.
Except they didn't. And CORBA.
We did have a course on Object Oriented Databases, which would obviously take over the world.
Except they didn't. And CORBA.
I've never worked with UML, but part of me wants to like it. Part of this is a reaction to (IMHO) an excess of "agile" methodology and a corresponding lack of forethought. The more intriguing part, however, is the idea of subdividing the problem using visual formalisms, and diving down into code to formalize the trickier bits.
I wonder if there's a clear boundary beyond which visual formalisms are no longer effective? I'm reminded of visual proofs in mathematics, and their reputation for being unreliable and misleading. It would be cool if we could identify a subset of cases where visual formalisms were (nearly) as rigorous as lexicographic ones, but nevertheless more intuitive.
I wonder if there's a clear boundary beyond which visual formalisms are no longer effective? I'm reminded of visual proofs in mathematics, and their reputation for being unreliable and misleading. It would be cool if we could identify a subset of cases where visual formalisms were (nearly) as rigorous as lexicographic ones, but nevertheless more intuitive.
This was actually more enlightening than I expected... Ultimately, I think it comes down to:
"...software culture shifted progressively towards large tech-first companies and startups. Neither, historically, was the target audience of CASE vendors."
> prominent people from the early days, including Grady Booch, Bertrand Meyer, and Ed Seidewitz
What does Bertrand Meyer have to do with the history of UML?
> they bought Jacobson’s consulting company and phased out OOSE.
Objectory was a much better tool than Rational Rose; never understood, why they killed it. The most useful features of UML and RUP came from Objectory (Rose only had clouds and arrows at that time).
> The Reasons
The given reasons are not very convincing. I would rather say that once again an originally good idea was blown up to such an extent that only the cargo cult league was completely satisfied with it, and everyone else realized that once again the wrong problem was being solved with a lot of effort.
What does Bertrand Meyer have to do with the history of UML?
> they bought Jacobson’s consulting company and phased out OOSE.
Objectory was a much better tool than Rational Rose; never understood, why they killed it. The most useful features of UML and RUP came from Objectory (Rose only had clouds and arrows at that time).
> The Reasons
The given reasons are not very convincing. I would rather say that once again an originally good idea was blown up to such an extent that only the cargo cult league was completely satisfied with it, and everyone else realized that once again the wrong problem was being solved with a lot of effort.
> What does Bertrand Meyer have to do with the history of UML?
Good question! While he wasn't involved with the standardization of it, he was one of the first major opponents, primarily because 1) was already a giant in OOP methodology, and 2) had a competing notation (BON). Also he was a real big stickler about "it's not really OOP if you're not using EIFFEL (tee em)". So he had a lot of firsthand knowledge of the early controversies and arguments and stuff.
Good question! While he wasn't involved with the standardization of it, he was one of the first major opponents, primarily because 1) was already a giant in OOP methodology, and 2) had a competing notation (BON). Also he was a real big stickler about "it's not really OOP if you're not using EIFFEL (tee em)". So he had a lot of firsthand knowledge of the early controversies and arguments and stuff.
I guess Objectory etc. was better suited for statemachine like systems like telephone systems. I.e. the tool is better at Ericsson where it was originally used than IBM.
No, it was general purpose and the direct predecessor of the initial UML and RUP versions. Here is a summary in case you're interested: https://www.ivarjacobson.com/publications/books/object-orien.... Objectory was the name of the method, the tool and the company as well. The tool supported the whole development process with fully cross-referenced model versions for each phase, model integrated editors with a kind of transclusion (see https://en.wikipedia.org/wiki/Transclusion), and a very powerful document generator; even round-trip engineering was supported. Unfortunately the tool vanished when Rational both them and you barely can find anything about it on the web.
Interesting. I could not find much about them.
Transclusion (yes I had to look it up) I feel would be an interesting property in development and the "auto complete" type of transclusion always feels like a hack.
I wonder how structured software engineering feels like in a big project. Everywhere I have been involved, there were no structure what so ever on the technical level, just process on features and resources.
Transclusion (yes I had to look it up) I feel would be an interesting property in development and the "auto complete" type of transclusion always feels like a hack.
I wonder how structured software engineering feels like in a big project. Everywhere I have been involved, there were no structure what so ever on the technical level, just process on features and resources.
> I could not find much about them.
I once asked Jacobson whether he would release the source code; unfortunately he wasn't able to do so; maybe the IP owners will change their minds some day (as others did with their outdated software).
> Transclusion
I rarely see implementations of it. Some years ago I built a tool which shares a small subset of features with Objectory (so the transcluding links between items); here is the link in case you're interested: https://github.com/rochus-keller/CrossLine.
I once asked Jacobson whether he would release the source code; unfortunately he wasn't able to do so; maybe the IP owners will change their minds some day (as others did with their outdated software).
> Transclusion
I rarely see implementations of it. Some years ago I built a tool which shares a small subset of features with Objectory (so the transcluding links between items); here is the link in case you're interested: https://github.com/rochus-keller/CrossLine.
There's a really nice "UML the good parts" within UML that is useful. Sequence diagrams, state diagrams, and class diagrams can instantly clarify a design. But go ahead and ignore the hollow vs solid arrows, dotted lines vs solid lines, etc. Those tend to be obvious from context.
The main reason I don't use UML more is that there really is no good UML diagramming software. It is either way too complex (tries to implement the whole UML "standard"), or else it is a general purpose drawing tool (you need to painstakingly connect arrows to boxes, etc)
UML was built for conference room whiteboards, and as a remote worker I haven't had a whiteboard in years.
The main reason I don't use UML more is that there really is no good UML diagramming software. It is either way too complex (tries to implement the whole UML "standard"), or else it is a general purpose drawing tool (you need to painstakingly connect arrows to boxes, etc)
UML was built for conference room whiteboards, and as a remote worker I haven't had a whiteboard in years.
2 reasons UML died:
1. Developers don't pay the kind of money they once did for development tools. Many don't pay anything at all. Those that do pay money typically only pay for an IDE (JetBrains or something like that).
2. The lack of financial incentive from (1) makes it so we haven't seen and likely will never see a round-trip UML tool - which is what's badly-needed to make UML an actual productive tool. The article mentions this. That's really too bad because such a tool would be worth its weight in gold - but good luck getting anyone to pay for it.
That's just where we are at the moment as an industry. Worse is better. Especially if worse is free (as in beer).
1. Developers don't pay the kind of money they once did for development tools. Many don't pay anything at all. Those that do pay money typically only pay for an IDE (JetBrains or something like that).
2. The lack of financial incentive from (1) makes it so we haven't seen and likely will never see a round-trip UML tool - which is what's badly-needed to make UML an actual productive tool. The article mentions this. That's really too bad because such a tool would be worth its weight in gold - but good luck getting anyone to pay for it.
That's just where we are at the moment as an industry. Worse is better. Especially if worse is free (as in beer).
A "round-trip UML tool" is actually impossible, except for in very limited circumstances.
UML itself doesn't provide enough detail to completely develop the code, and the code doesn't provide enough model hints to completely develop the UML.
When there is enough detail, the diagrams become unreadable and the code becomes unmaintainable.
So every "round-trip" details are lost. People have been trying to solve this problem generally for 40 years. It's a lost cause.
UML itself doesn't provide enough detail to completely develop the code, and the code doesn't provide enough model hints to completely develop the UML.
When there is enough detail, the diagrams become unreadable and the code becomes unmaintainable.
So every "round-trip" details are lost. People have been trying to solve this problem generally for 40 years. It's a lost cause.
When I left the UML world 15 years ago what was being worked on was the model. Not everything in the model has to be expressed in the diagram(s) - that simply makes the diagrams unusable. The problem is UML "grew up" being diagram-based, which can't be round-tripped. Too many people rejected the model approach and the two factors I identified were then able to kill it.
I disagree with the premise, because the major tech companies are so good about releasing open source developer tools.
For example a unit testing framework is a really important developer tool. And we have great unit testing frameworks because Google has the firepower to invest in Googletest for its internal developers, then released Googletest to the world.
If UML was really productivity enhancing, I'm pretty sure Google would be using it. Even if it had to build it from scratch, a 1% improvement in developer productivity would easily amortize their cost to build a fantastic, open source UML tool.
For example a unit testing framework is a really important developer tool. And we have great unit testing frameworks because Google has the firepower to invest in Googletest for its internal developers, then released Googletest to the world.
If UML was really productivity enhancing, I'm pretty sure Google would be using it. Even if it had to build it from scratch, a 1% improvement in developer productivity would easily amortize their cost to build a fantastic, open source UML tool.
Meh. The industry has spent the past 15 years preaching "emergent architecture and design." The fear of BUFD (big, up-front design) has shifted the pendulum to the opposite extreme: little or minimal design. So here we are. I still think there's a lot we can do with CASE (computer-aided software engineering) - just not in the way we envisioned in the 80s and 90s.
> I still think there's a lot we can do with CASE (computer-aided software engineering)
I'm pretty biased towards minimal upfront design. At least of the formal variety. But I'd like to make sure I'm not missing some low hanging fruit for easy improvements. Do you have any recommended reading for what you're talking about w.r.t. to CASE?
I'm pretty biased towards minimal upfront design. At least of the formal variety. But I'd like to make sure I'm not missing some low hanging fruit for easy improvements. Do you have any recommended reading for what you're talking about w.r.t. to CASE?
No - the industry abandoned CASE in the 90's and the pendulum swung back the other way. I worked for a company in the early 90's that bought into case hard. I never thought CASE was about the tool writing all your code - but they sure did! What a nightmare! I'd like to see CASE used to capture big-picture items, major information flows, configuration management handling and the like. I'd like to see UML diagrams dynamically generated from the underlying model. Utilize a query language to allow me to select a class and see what all it derives from and see what it interacts with - graphically. It's another way of interacting with a code base. That's the stuff I'd like to see us get to.
Back in 2011 we built yatta solutions as a startup around template based roundtrip engineering. UML lab would use templates to not only generate the source code from UML diagrams but also to 'parse' the code.
I don't know the current state of https://www.uml-lab.com/en/uml-lab/ because I left for other adventures, but if you are looking for a tool that can actually keep code and UML in sync give it a try.
I don't know the current state of https://www.uml-lab.com/en/uml-lab/ because I left for other adventures, but if you are looking for a tool that can actually keep code and UML in sync give it a try.
I started my career at CMG, a big consultancy now called Logica. They were BIG on UML and Rational Unified Process.
I had no clue what I was doing so I gobbled it up. "So THIS is how you make software, ahaaaaaaa!"
After leaving CMG I have never, ever seen it used in the wild by any remotely successful company or team. I would say it is a clear red flag even.
Sequence diagrams are the only thing I sometimes use to get a grip on how APIs should talk to each other or how flows between integrations should be.
I had no clue what I was doing so I gobbled it up. "So THIS is how you make software, ahaaaaaaa!"
After leaving CMG I have never, ever seen it used in the wild by any remotely successful company or team. I would say it is a clear red flag even.
Sequence diagrams are the only thing I sometimes use to get a grip on how APIs should talk to each other or how flows between integrations should be.
Logica no longer exists - gobbled up by the Canadian company CGI in 2012.
Ah right that's true. Their stock had tanked very, very hard I remember. My option plan was worth zilch. I left in 2003 already and didn't really follow it after that.
I asked my kids (all software engineers) this same question about a year ago. My daughter said it was because class diagrams became too complicated for uml.
I used to use uml class diagrams when coming up to speed on a new framework. I tried to do this recently and it was a nightmare.
I used to use sequence diagrams for my own code - but that is difficult to derive from someone else's code.
I used to use uml class diagrams when coming up to speed on a new framework. I tried to do this recently and it was a nightmare.
I used to use sequence diagrams for my own code - but that is difficult to derive from someone else's code.
The reason why UML died is muuuch simpler. It simply promised what it could never deliver.
Unlike what UML is trying to simulate, which is an architectural blueprint, a UML model of a system cannot be verified for correctness. But a blueprint can be verified; You can tell "that proposed bridge" will hold "so much traffic and wind" by studying the blueprint.
Unlike what UML is trying to simulate, which is an architectural blueprint, a UML model of a system cannot be verified for correctness. But a blueprint can be verified; You can tell "that proposed bridge" will hold "so much traffic and wind" by studying the blueprint.
UML has the same problem as every other graphical programming language: nobody has solved the problem of diffing two versions of the 'code'.
Most code is verified for correctness by human eyeballs. I think many of us underestimate how important the 'diff' is with respect to incremental reasoning, which we do more often than not to keep the costs down. Once in a while we 'audit' the system, considering the model as a whole, but more often than not we are thinking in terms of deltas versus previous expectations.
Whoever actually solves the visual diff problem, I would be happy to see nominated for a Turing award. It's that big of a hill to climb.
Most code is verified for correctness by human eyeballs. I think many of us underestimate how important the 'diff' is with respect to incremental reasoning, which we do more often than not to keep the costs down. Once in a while we 'audit' the system, considering the model as a whole, but more often than not we are thinking in terms of deltas versus previous expectations.
Whoever actually solves the visual diff problem, I would be happy to see nominated for a Turing award. It's that big of a hill to climb.
The article mentions text representations of diagrams.
Has anyone had success with sites like https://sequencediagram.io/ or using "DrawIO" inside VScode?
Has anyone had success with sites like https://sequencediagram.io/ or using "DrawIO" inside VScode?
Yes! PlantUML, DrawIO, WebSequenceDiagrams, even the dot file format of Graphviz, they are good. You can keep the source in the repo with your other code, and it is just another form of documentation (with all the caveats that implies). I gave up trying to use any visual tool to create the diagrams, though. Too slow, too clunky, too fiddly.
I enjoyed learning about UML in CS grad school. It was super tedious and arcane, but now in industry as a product manager, I realize that there's value in different types of diagrams. Not everything is a flowchart.
Functional programming trends killed it imo. Map filter reduce make up a big part of the code I write and it takes longer to write the hard-to-read UML version of those than it does to write the actual implementation.
As a CS undergrad taking a course in Software Engineering,
where we are currently studying UML, I wonder what the alternatives are? What tools/methods are used in practice, today, instead of UML?
In my experience, the broad concepts of UML are applicable and used in real-world engineering/design. By "broad concepts" I mean something like "draw boxes for classes/objects with arrows pointing to related other objects".
Thinking about systems as state machines, sequences, entity relationships, etc is useful. But the rigid details of specific lines styles, arrow types, etc are very rarely used.
Thinking about systems as state machines, sequences, entity relationships, etc is useful. But the rigid details of specific lines styles, arrow types, etc are very rarely used.
Sometimes it seem like "nothing" is used today. People just start writing code. This actually isn't a bad way to go 70% of the time. But if you find yourself struggling it might be time to step back and think it out with some informal UML sketches. Nobody uses "formal" UML anymore.
The main risk of UML is it can lead to overly complex designs - it is so easy to add another box and arrow, to make it match a GOF pattern, etc.
As for what we use here in practice today - pairing and talking out ideas sometimes with informal UML sketch, and test driven development.
The main risk of UML is it can lead to overly complex designs - it is so easy to add another box and arrow, to make it match a GOF pattern, etc.
As for what we use here in practice today - pairing and talking out ideas sometimes with informal UML sketch, and test driven development.
Design a notation based on existing norms to whatever specificity you deem adequate).
I like process boxes with four sides.
Left side takes input, the right spits output.
Top side takes constraints, rules, or links to specs.
Bottom accepts triggering mechanism, temporal/sequential constraints, polling, and other controls.
Complex Processes get decomposed down to autonomous objects that can be programmed as desired.
Many of the stripped down existing iconic notations can be similarly instrumented to be useful. Be your own guru.
I like process boxes with four sides.
Left side takes input, the right spits output.
Top side takes constraints, rules, or links to specs.
Bottom accepts triggering mechanism, temporal/sequential constraints, polling, and other controls.
Complex Processes get decomposed down to autonomous objects that can be programmed as desired.
Many of the stripped down existing iconic notations can be similarly instrumented to be useful. Be your own guru.
You're fine. Draw some useful diagrams. Sometimes, generate useful diagrams from parts of code you're having issues understanding (Doxygen, with a little help, can do it). Do not try to create a diagram and generate code from it, and definitely don't ever attempt round-tripping your code and diagrams.
Use the syntax, don't get caught up in the tooling.
Use the syntax, don't get caught up in the tooling.
UML died because people just want to open up draw.io and put down a few boxes and arrows, and they don't want the mental overhead of having to use a formal language for doing this.
You start with an informal idea of what the program will do and how it will work, and you proceed from there to something formal (at a minimum, by the time you get to the code). Along the way, diagrams are useful for refining your own thinking, and for communicating with others.
So I think what you're saying is that people want those diagrams to be on the informal side of the formal/informal divide, and UML tried to put them on the formal side. And that didn't work, because on the informal side, a diagram can communicate the general idea quickly. But on the formal side, diagrams are very tedious to produce in the detail required for a formal design, and even more tedious to edit to keep up to date as the design evolves.
UML died because diagrams work better for informal rather than formal communication. I think that explanation fits rather well.
So I think what you're saying is that people want those diagrams to be on the informal side of the formal/informal divide, and UML tried to put them on the formal side. And that didn't work, because on the informal side, a diagram can communicate the general idea quickly. But on the formal side, diagrams are very tedious to produce in the detail required for a formal design, and even more tedious to edit to keep up to date as the design evolves.
UML died because diagrams work better for informal rather than formal communication. I think that explanation fits rather well.
UML died because diagrams work better for informal rather than formal communication. I think that explanation fits rather well.
That would be a great surprise indeed to mechanical engineers, chemical process plant engineers, electricians, analog circuit designers, machinists, architects, PureData livecoders in nightclubs, and many other groups of people. UML's problem wasn't that it was visual. UML's problem is that it was a fraud: https://news.ycombinator.com/item?id=26956298
That would be a great surprise indeed to mechanical engineers, chemical process plant engineers, electricians, analog circuit designers, machinists, architects, PureData livecoders in nightclubs, and many other groups of people. UML's problem wasn't that it was visual. UML's problem is that it was a fraud: https://news.ycombinator.com/item?id=26956298
Then add in 'agile'. Which for some people seem to translate into just throw some code down and work out the details later. Oh then keep your docs up to date (many devs detest doc work). Then add in the cost for a RR seat (wasnt it like 20k per dev at one point?). Then add in the agile is a strict set of rules people (5 stages before story creation) while you were getting your UML just right for your story we finished the epic and the user signed off already.
A few boxes on a whiteboard and some lines usually is more than sufficient for many things.
A few boxes on a whiteboard and some lines usually is more than sufficient for many things.
Because Object-Orientation was always a real PITA and not particularly relevant to mapping to real-world problems, despite the fact that that was its initial selling point?
That's definitely true about OOAD. The whole point of development methodologies like RUP was that every step in design, from requirements analysis to large-scale modeling and actual implementation, should be structured around domain 'objects'. That kind of rigid approach does little to address the actual problems of modular software design; there's no reason to expect it to give satisfactory outcomes.
Great recap.
I remember being invited by IBM to a round table with Grady Booch. The guy just mouthed platitudes worthy of an architecture astronaut, and utterly disconnected with reality.
I remember being invited by IBM to a round table with Grady Booch. The guy just mouthed platitudes worthy of an architecture astronaut, and utterly disconnected with reality.
UML is an artifact of trying to sell products as part of the Waterfall model of software development. It wasn't very useful even at its peak.
It was Rational software pushing their process and CASE tools.
It was an awful, inefficient and bureaucratic process that made it easy to write contracts about deliverables while delivering mostly no actual value to the customers.
It was Rational software pushing their process and CASE tools.
It was an awful, inefficient and bureaucratic process that made it easy to write contracts about deliverables while delivering mostly no actual value to the customers.
Agile is a refinement of Waterfall. I think of it as the white water rafting SDLC of waterfall.
The minute sticky notes in swim lanes and informal diagramming were replced by heavyweight, middle-managers (-cough- "agile coach") - waterfall is back.
Rational is one factor of many that brought IBM to its knees -(WARP-OS2) being a contemporary.
The minute sticky notes in swim lanes and informal diagramming were replced by heavyweight, middle-managers (-cough- "agile coach") - waterfall is back.
Rational is one factor of many that brought IBM to its knees -(WARP-OS2) being a contemporary.
On round-tripping, anyone remember Together-J? Realtime round-tripping between UML and Java.
Was going to find a place in here to comment on Together.
I remember spending $1500k on a professional license circa 1999, and still think it was the best money I've ever spent on an IDE. Incredibly powerful for large-scale systems, and made large-scale, readable-code development fast.
I remember spending $1500k on a professional license circa 1999, and still think it was the best money I've ever spent on an IDE. Incredibly powerful for large-scale systems, and made large-scale, readable-code development fast.
UML died because it was a fraud.
The biggest UML proponents (sometimes including Rational) weren't promoting it for informal design sketching—for which it works well!—or even just blueprinting; they were promoting it for higher-level formal modeling and specification of system design and behavior, including especially software systems. Given such a formal model, the charlatans explained, you could find design errors earlier in the process and fix them before proceeding to implementation work, and you could rigorously verify that the system actually built fulfilled its requirements.
These are very useful properties, and clearly such model-driven development could save a great deal of time and money. The problem is that they have nothing to do with UML's actual capabilities; selling UML as a path to this utopia was just a lie. Things like TLA+, Alloy, Coq, Hypothesis, and even JUnit can sometimes deliver on some of those promises, but UML can't. Hillel Wayne explains why in this newsletter: UML never had the formal semantics necessary to deliver these properties; its implementations were buggy, incomplete, and unmaintained; and it also suffered from the same kind of specification drift that leads to out-of-date comments and useless unit tests in common practice.
So I think what happened is that some companies tried UML and the associated SEI CMM processes, found that the promises were a fraud, and abandoned those processes. Other companies saw that the companies in the first group were doing badly, so they tried other things. I seem to recall an ad (!) for Extreme Programming in Dr. Dobb's Journal about 20 years ago: it ridiculed SEI-style heavyweight processes with a cartoon of a sumo wrestler trying to run a marathon.
And some companies did adopt Extreme Programming, which does deliver on some of those promises, a little; XP hammers pretty hard on, among other things, simplifying your design, formalizing all your system's requirements with unit tests and acceptance tests (though of course these are not very rigorous), and constantly and automatically verifying the system's conformance to those tests. And 02003 is about when XP started to take off, inspiring the adoption of fraudulent methodologies like Scrum that promised XP's benefits without its costs†, much as UML promised the benefits of formal methods without their costs.
(XP is no panacea, of course; if you don't know how to design software, it can't produce a software design for you, and if you don't know how to program, it can't write the code for you, as UML proponents have frequently promised UML will do. XP's extremely weak formalization of requirements as pointwise automated tests just provides a feedback loop that tells you when you're digging yourself into a deeper hole and focuses your efforts, such as they are, on things that matter to the project. Today formal methods have advanced to the point that it's practical to do much better than XP, but that future is still not evenly distributed. Myself, I've barely managed to adopt Hypothesis, and productive use of Z3, TLA+, Coq, or even Alloy or miniKANREN is still beyond my skills.)
— ⁂ —
The kind of methodological swindle represented by Scrum and UML is not a new phenomenon. In 02005 I wrote '"Enterprise software" is a social, not technical, phenomenon', https://web.archive.org/web/20050812004045/http://lists.cano... reflecting on my experiences writing so-called "enterprise software" and how its institutional imperatives systematically eliminate the feedback loops necessary for software development to actually create economic value; and in 01988 Dijkstra wrote EWD 1036, "On the cruelty of really teaching computing science", https://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/E..., containing the memorable quote, 'Software engineering, of course, presents itself as another worthy cause, but that is eyewash: if you carefully read its literature and analyse what its devotees actually do, you will discover that software engineering has accepted as its charter "How to program if you cannot.".'
Dijkstra had been skewering this kind of stupidity for decades at that point‡, but as long as the technically incompetent desperately seek answers to "How to program if you cannot" instead of dedicating the necessary effort to improving themselves, there will be no shortage of scam artists offering sham solutions like (the exaggerated claims that sold) UML. When they are forced to compete in the marketplace their companies will gradually lose to competitors managed by less ignorant people—Google, Apple, and Microsoft have long since buried Excite, Commodore, and Ashton-Tate—but UML remains very popular among defense contractors, since their profits are not contingent on operational efficiency or even producing working products at all.
Let us hope that real formal methods are not tarnished by conflation with UML-style con jobs in the way that XP has been tarnished by conflation with Scrum.
______
† Scrum existed before 02003, and before 02001—Schwaber outlined it and named it in a 01995 paper that advocates a recognizable, if handwavy, version of that anti-intellectual abortion we call Scrum today—but essentially the Agile Manifesto in 02001 was a political strategy to hitch it to XP's rising star, and Scrum started to achieve significant adoption around 02005 as a result of that association.
‡ For example, in 01975 in EWD512 he commented, "Already many a large organisation is nearly crushed under the sheer weight of the illogical, unmastered complexity of its automatic data processing systems." EWD511 laments the lousy design of the 360 and IBM's attempts to promote it. EWD406, from 01973, contains further remarks on, especially, LANL and CDC after Cray's departure; EWD407 complains, "Simple souls have been made to believe that we have a retail shop in Philosopher’s Stones that, by magic, will cure all diseases," a theme that also appears in EWD406. In EWD483, in 01977, he thunders:
Shortly after World War II, when [the students this speech was originally given to] did not yet exist, my physics teacher drew our attention to the fact that we had had the Stone Age, then the Bronze Age, then the Iron Age, and then, in the Netherlands at least, the Golden Age—but that the 20th century would go down in history as the Age of Incompetence (after which it became the order of the day). More than a quarter of a century later, I would like to add a modest extra: it will be recorded in history as the Age of Fraud. This is the widespread phenomenon which the little whitewash artist refers to as "wishful thinking", but to the infidel eye it is no different from ordinary, vulgar deception, namely the deception that consists of the desire to do something, being replaced indiscriminately through faith, and then the pretense of being able to do that thing. … Long is the list of organizations that, after having begun a task for which the competence was lacking, either went bust or managed to save their lives by saddling society with their inferior product, thanks to chicanery.
This is a fairly precise description of Rational's business model, four years before the company was founded. (Corrections on the translation from Dutch would be appreciated; my Dutch skills are even worse than my miniKANREN skills.)
The biggest UML proponents (sometimes including Rational) weren't promoting it for informal design sketching—for which it works well!—or even just blueprinting; they were promoting it for higher-level formal modeling and specification of system design and behavior, including especially software systems. Given such a formal model, the charlatans explained, you could find design errors earlier in the process and fix them before proceeding to implementation work, and you could rigorously verify that the system actually built fulfilled its requirements.
These are very useful properties, and clearly such model-driven development could save a great deal of time and money. The problem is that they have nothing to do with UML's actual capabilities; selling UML as a path to this utopia was just a lie. Things like TLA+, Alloy, Coq, Hypothesis, and even JUnit can sometimes deliver on some of those promises, but UML can't. Hillel Wayne explains why in this newsletter: UML never had the formal semantics necessary to deliver these properties; its implementations were buggy, incomplete, and unmaintained; and it also suffered from the same kind of specification drift that leads to out-of-date comments and useless unit tests in common practice.
So I think what happened is that some companies tried UML and the associated SEI CMM processes, found that the promises were a fraud, and abandoned those processes. Other companies saw that the companies in the first group were doing badly, so they tried other things. I seem to recall an ad (!) for Extreme Programming in Dr. Dobb's Journal about 20 years ago: it ridiculed SEI-style heavyweight processes with a cartoon of a sumo wrestler trying to run a marathon.
And some companies did adopt Extreme Programming, which does deliver on some of those promises, a little; XP hammers pretty hard on, among other things, simplifying your design, formalizing all your system's requirements with unit tests and acceptance tests (though of course these are not very rigorous), and constantly and automatically verifying the system's conformance to those tests. And 02003 is about when XP started to take off, inspiring the adoption of fraudulent methodologies like Scrum that promised XP's benefits without its costs†, much as UML promised the benefits of formal methods without their costs.
(XP is no panacea, of course; if you don't know how to design software, it can't produce a software design for you, and if you don't know how to program, it can't write the code for you, as UML proponents have frequently promised UML will do. XP's extremely weak formalization of requirements as pointwise automated tests just provides a feedback loop that tells you when you're digging yourself into a deeper hole and focuses your efforts, such as they are, on things that matter to the project. Today formal methods have advanced to the point that it's practical to do much better than XP, but that future is still not evenly distributed. Myself, I've barely managed to adopt Hypothesis, and productive use of Z3, TLA+, Coq, or even Alloy or miniKANREN is still beyond my skills.)
— ⁂ —
The kind of methodological swindle represented by Scrum and UML is not a new phenomenon. In 02005 I wrote '"Enterprise software" is a social, not technical, phenomenon', https://web.archive.org/web/20050812004045/http://lists.cano... reflecting on my experiences writing so-called "enterprise software" and how its institutional imperatives systematically eliminate the feedback loops necessary for software development to actually create economic value; and in 01988 Dijkstra wrote EWD 1036, "On the cruelty of really teaching computing science", https://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/E..., containing the memorable quote, 'Software engineering, of course, presents itself as another worthy cause, but that is eyewash: if you carefully read its literature and analyse what its devotees actually do, you will discover that software engineering has accepted as its charter "How to program if you cannot.".'
Dijkstra had been skewering this kind of stupidity for decades at that point‡, but as long as the technically incompetent desperately seek answers to "How to program if you cannot" instead of dedicating the necessary effort to improving themselves, there will be no shortage of scam artists offering sham solutions like (the exaggerated claims that sold) UML. When they are forced to compete in the marketplace their companies will gradually lose to competitors managed by less ignorant people—Google, Apple, and Microsoft have long since buried Excite, Commodore, and Ashton-Tate—but UML remains very popular among defense contractors, since their profits are not contingent on operational efficiency or even producing working products at all.
Let us hope that real formal methods are not tarnished by conflation with UML-style con jobs in the way that XP has been tarnished by conflation with Scrum.
______
† Scrum existed before 02003, and before 02001—Schwaber outlined it and named it in a 01995 paper that advocates a recognizable, if handwavy, version of that anti-intellectual abortion we call Scrum today—but essentially the Agile Manifesto in 02001 was a political strategy to hitch it to XP's rising star, and Scrum started to achieve significant adoption around 02005 as a result of that association.
‡ For example, in 01975 in EWD512 he commented, "Already many a large organisation is nearly crushed under the sheer weight of the illogical, unmastered complexity of its automatic data processing systems." EWD511 laments the lousy design of the 360 and IBM's attempts to promote it. EWD406, from 01973, contains further remarks on, especially, LANL and CDC after Cray's departure; EWD407 complains, "Simple souls have been made to believe that we have a retail shop in Philosopher’s Stones that, by magic, will cure all diseases," a theme that also appears in EWD406. In EWD483, in 01977, he thunders:
Shortly after World War II, when [the students this speech was originally given to] did not yet exist, my physics teacher drew our attention to the fact that we had had the Stone Age, then the Bronze Age, then the Iron Age, and then, in the Netherlands at least, the Golden Age—but that the 20th century would go down in history as the Age of Incompetence (after which it became the order of the day). More than a quarter of a century later, I would like to add a modest extra: it will be recorded in history as the Age of Fraud. This is the widespread phenomenon which the little whitewash artist refers to as "wishful thinking", but to the infidel eye it is no different from ordinary, vulgar deception, namely the deception that consists of the desire to do something, being replaced indiscriminately through faith, and then the pretense of being able to do that thing. … Long is the list of organizations that, after having begun a task for which the competence was lacking, either went bust or managed to save their lives by saddling society with their inferior product, thanks to chicanery.
This is a fairly precise description of Rational's business model, four years before the company was founded. (Corrections on the translation from Dutch would be appreciated; my Dutch skills are even worse than my miniKANREN skills.)
No. UML was not a fraud. It's a modeling language that abstracts, using highly specific iconic vernaculars, numerous technical views of interest relating to software development.
By definition, that task was never going to be an easy nor mutable exercise. If fraud existed it was in the marketing of the CASE tools UML was embedded in. The claims and expectations were wholly orthogonal to software engineering practice of that or any time.
If memory serves me correctly, mainframe commercial development projects routinely failed or required as much budget and time to complete at anticipated delivery as when they had initially started. The white-collar blame was assigned to the quality of development.
The push back legitimately was the assertion that requirements constantly changed (and how could they not?). The self-anointed gurus of the time responded by creating smoke and mirrors solutions that largely manifested themselves in exclusive, eclectic, and proprietary modeling languages. The predictable collapse of that circular firing squad set of methodologies spawned UML under the bastard thumb of IBM (Rational). Big investment means and meant exclusive, profit-driven ambitions, not fraud - self-serving, big money investment.
The client community was drowned in error rate charts, line-of-code (LOC) costs, and business baby-talk illustrations of before and after CASE development anticipated savings.
This form of techno-magic ponzi scheme is still being played Agile-wide. Once the client makes a sizable investment in the pixie dust they will never admit it was a waste of time and money.
And, just for the record, there were critics, sensible advocates, and sober analysts who were ignored, slandered, and whose careers were rougher had they not bothered.
By definition, that task was never going to be an easy nor mutable exercise. If fraud existed it was in the marketing of the CASE tools UML was embedded in. The claims and expectations were wholly orthogonal to software engineering practice of that or any time.
If memory serves me correctly, mainframe commercial development projects routinely failed or required as much budget and time to complete at anticipated delivery as when they had initially started. The white-collar blame was assigned to the quality of development.
The push back legitimately was the assertion that requirements constantly changed (and how could they not?). The self-anointed gurus of the time responded by creating smoke and mirrors solutions that largely manifested themselves in exclusive, eclectic, and proprietary modeling languages. The predictable collapse of that circular firing squad set of methodologies spawned UML under the bastard thumb of IBM (Rational). Big investment means and meant exclusive, profit-driven ambitions, not fraud - self-serving, big money investment.
The client community was drowned in error rate charts, line-of-code (LOC) costs, and business baby-talk illustrations of before and after CASE development anticipated savings.
This form of techno-magic ponzi scheme is still being played Agile-wide. Once the client makes a sizable investment in the pixie dust they will never admit it was a waste of time and money.
And, just for the record, there were critics, sensible advocates, and sober analysts who were ignored, slandered, and whose careers were rougher had they not bothered.
> If fraud existed it was in the marketing of the CASE tools UML was embedded in.
Yes, that was the claim I intended to make. Thank you for saying it more clearly.
> smoke and mirrors solutions…proprietary modeling languages…predictable collapse…Big investment means and meant exclusive, profit-driven ambitions,
Yes, yes! I can see we totally agree!
> not fraud
Wait, doesn't that contradict the entire rest of your comment, including the immediately previous and following phrases, "profit-driven ambitions" and "self-serving, big money investment"? How can something both be a "smoke and mirrors" "self-serving" "Ponzi scheme" and also be "not fraud"?
It sounds like you agree with all my factual claims, adding supporting points of your own for them, but you think "fraud" is not the right word to use? Why not? My best guess at this point is that you don't know what the word "fraud" means.
Also, as a side note, I have no idea what this sentence is supposed to mean:
> By definition, that task was never going to be an easy nor mutable exercise.
Yes, that was the claim I intended to make. Thank you for saying it more clearly.
> smoke and mirrors solutions…proprietary modeling languages…predictable collapse…Big investment means and meant exclusive, profit-driven ambitions,
Yes, yes! I can see we totally agree!
> not fraud
Wait, doesn't that contradict the entire rest of your comment, including the immediately previous and following phrases, "profit-driven ambitions" and "self-serving, big money investment"? How can something both be a "smoke and mirrors" "self-serving" "Ponzi scheme" and also be "not fraud"?
It sounds like you agree with all my factual claims, adding supporting points of your own for them, but you think "fraud" is not the right word to use? Why not? My best guess at this point is that you don't know what the word "fraud" means.
Also, as a side note, I have no idea what this sentence is supposed to mean:
> By definition, that task was never going to be an easy nor mutable exercise.
Factual claims are not the same as fraud. Lots of people consume vitamin supplements. Why? Fraud? No, people believe what they want to believe about products that are legal to sell.
CASE tools were/are no different. You and I have our concerns but P.T. Barnum reminds us, "there's a sucker born every minute!"
The task of unifying and consolidating all of the worthwhile details required in Iconic notation to truly capture the complexity of the thing was never going to be easy nor a finite goal. (e.g. it's a whack-a-mole exercise that doesn't end)
But quite honestly, we are on the same page. If you liken it to fraud - not my monkey, not my circus.
CASE tools were/are no different. You and I have our concerns but P.T. Barnum reminds us, "there's a sucker born every minute!"
The task of unifying and consolidating all of the worthwhile details required in Iconic notation to truly capture the complexity of the thing was never going to be easy nor a finite goal. (e.g. it's a whack-a-mole exercise that doesn't end)
But quite honestly, we are on the same page. If you liken it to fraud - not my monkey, not my circus.
The push is gone? IE, the three amigos retired.
I think the only one who retired during the early decline was Rumbaugh; as one person told me, "he got out while the going was good." Grady Booch left modeling later. Ivar Jacobson is still around, though now he pitches his Essence framework. I always got the feeling he was the least "amigo" of the three, which makes sense given he joined due to a hostile takeover.
The "real reason"? MSFT was making too much money selling developer tools. If you automate app creation from specs (totally doable with UML for most CRUD apps), then it would have greatly impacted Microsoft's revenue.
You base this theory on...? Because I worked at MSFT at the height of the UML craze, in the Developer Tools division to boot, and the "DevDiv must make money"[0] mandate didn't come down until after the industry had collectively decided to move on from UML. Additionally, who do you think was going to stand ready to sell you the tool that "automate(s) app creation from specs"? Ever see a copy of VS 2003-ish?
Conspiracy theories are fun, but the "real" reason is in one of the several articles floating around HN that past few days. Mainly, it was a disorganized mess that no one was going to build tools for. Then IBM got hold of it, then...
[0] Previously it was, "we don't care if it makes money as long as it supports the Windows platform", hence the "developers, developers, developers" from Ballmer that folks like to dunk on. I was a grunt in DevDiv, so take it all with a grain of salt.
Conspiracy theories are fun, but the "real" reason is in one of the several articles floating around HN that past few days. Mainly, it was a disorganized mess that no one was going to build tools for. Then IBM got hold of it, then...
[0] Previously it was, "we don't care if it makes money as long as it supports the Windows platform", hence the "developers, developers, developers" from Ballmer that folks like to dunk on. I was a grunt in DevDiv, so take it all with a grain of salt.
Not a theory. I've heard it from MSFT product managers.
> stand ready to sell you the tool
There are a few - they've never been from MSFT
> stand ready to sell you the tool
There are a few - they've never been from MSFT
Many companies tried to automate app creation like that. The entire CASE industry mentioned in the article was working on that.
Not one of them produced anything worth using. It was nothing to do with Microsoft.
The real reason that UML died is that it was a solution in search of a problem that it could actually solve. It was one that had a lot of appeal for people, so it took longer to die than it should have. But it died because in practice, it was largely useless.
The real reason that UML died is that it was a solution in search of a problem that it could actually solve. It was one that had a lot of appeal for people, so it took longer to die than it should have. But it died because in practice, it was largely useless.
[deleted]
CASE is a very 1990s term - definitely deprecated.
UML is awesome IMHO and I've used it on every CRUD app that I've built. I am saddened about it's lack of widespread use.
UML is awesome IMHO and I've used it on every CRUD app that I've built. I am saddened about it's lack of widespread use.
The point about CASE is that there was a whole segment of the industry focused on addressing this problem, and it basically went nowhere.
Today there are a zillion CRUD generator tools, most of which don't use UML. It's not difficult. Many people who've worked on CRUD apps have probably written some autogeneration thing themselves at some point. Automating some boilerplate code generation doesn't solve any challenging problem in software development.
Today there are a zillion CRUD generator tools, most of which don't use UML. It's not difficult. Many people who've worked on CRUD apps have probably written some autogeneration thing themselves at some point. Automating some boilerplate code generation doesn't solve any challenging problem in software development.
UML has died, because any attempt to build an application automatically from UML led to endless discussions about association vs. composition and generalization vs. implementation.
Nah. The real reason was that framework evolution outpaced the ability of Model Driven Architecture tools to adapt to changing technology.
I know, I used to work on one such MDA tool. It first started with the assumption that you want to generate a J2EE application. By the time the code generation was "good" Spring and Hibernate came along and simplified things to the point that it was easier and faster to "just code."
Turning UML into executable code could be done in one of two ways. Transform one high-level model into an implementation-specific model and generate code from that, or, create a UML VM that could run the models directly.
The latter would have been the correct solution, and still would be more complicated than it's worth.
Use UML for communication. It's still good at that.
I know, I used to work on one such MDA tool. It first started with the assumption that you want to generate a J2EE application. By the time the code generation was "good" Spring and Hibernate came along and simplified things to the point that it was easier and faster to "just code."
Turning UML into executable code could be done in one of two ways. Transform one high-level model into an implementation-specific model and generate code from that, or, create a UML VM that could run the models directly.
The latter would have been the correct solution, and still would be more complicated than it's worth.
Use UML for communication. It's still good at that.
a spec precise enough to describe an "app" is a program. A person who creates such a spec is a programmer.
Can't tell if you're joking but one of the selling points of Microsofts paid versions of Visual Studio used to be good support for writing classes using UML. Microsoft is the O.g low-code company spending most of the 00s making people do things in diagrams and form builders of different kinds.
Partially joking. But really - MSFT has no incentive to reduce the required dev head count by tenfold.
they do. MSFT does not have monopoly on software. they compete with others. and have incentive to make life easier for their customers ... to destroy competitors
The money motivation isn’t that relevant but there’s some truth here. I used to work for a CASE tool company and I have long attributed their decline to the rise of IDEs and other programmer productivity tools. And not a bad thing either.
It died because big tech companies realized that their real customers are reserve banks; big tech companies are being paid for job creation, not product development. UML allows companies to build high quality software faster so it destroys jobs.
If UML did any such thing, IBM would be a trillion dollar company by now.
> UML allows companies to build high quality software faster so it destroys jobs.
Multiplying per-worker output in a field whose output isn’t limited by capital or raw materials doesn’t destroy jobs, it creates them.
Multiplying per-worker output in a field whose output isn’t limited by capital or raw materials doesn’t destroy jobs, it creates them.
The kind of software which creates more jobs is not what I would call 'quality software'. Quality software gives people more free time, it doesn't consume more time.
The fact that most people can't see the difference today is disturbing. It's a sign that we are trapped in an inefficiency mindset. We're always looking to solve problems in ways which create more problems instead of solving problems once and for all and then focusing on different problems.
The fact that most people can't see the difference today is disturbing. It's a sign that we are trapped in an inefficiency mindset. We're always looking to solve problems in ways which create more problems instead of solving problems once and for all and then focusing on different problems.
UML has never done anything of the kind. I've never read any case studies outside of marketing that claimed that UML increased software quality in any concrete and measurable way.
> UML has never done anything of the kind.
That may be true, I’m just saying even jf it did, that wouldn't make it a job killer but a job enabler. The whole reason computing is a growing field is it keeps inventing ways to multiply its own output. If that caused the field to shrink, the progressive move from punch cards to IDEs would have destroyed the field.
That may be true, I’m just saying even jf it did, that wouldn't make it a job killer but a job enabler. The whole reason computing is a growing field is it keeps inventing ways to multiply its own output. If that caused the field to shrink, the progressive move from punch cards to IDEs would have destroyed the field.
Since Rational was sold in 2003, UML has just been lurching from one generation of engineers to another shouting 'braaaiiins'.
Trying to discuss UML objectively without the context of who was selling what at the time is pointless. It was never a good enough method to live beyond being kept on life support by the marketers.