> Over the past two decades, though, software culture shifted progressively towards large tech-first companies and startups.
I think that this is also part of the reason why there has been a shift away from design patterns (e.g. Gang of Four, Patterns of Enterprise Application Architecture): the training that it required to be a proficient software engineer 20 years ago isn't the same as it is now.
No StackOverflow, no YouTube, a lot of documentation still on paper, etc.
So you'd get a CS degree, read, learn, and apply the knowledge.
That formula has inverted.
Nowadays, you can build and learn along the way. Watch a tutorial and learn "just-in-time". But this also means that there's really no reason to get into complex topics like modeling, "formal" diagramming, and even design patterns.
> I think that this is also part of the reason why there has been a shift away from design patterns (...)
There is no such shift. Design patterns are ubiquitous and more popular than ever. Some frameworks explicitly base their added value on providing a specific design pattern.
A design pattern is a higher level construct. It makes absolutely no sense to claim that there's a shift away from higher level constructs when the whole point of programming is using a lower-level programming language to implement higher-level abstractions that implement our requirements.
I think that we may be shifting away from is a particular form of design pattern fetishism: abusing design patterns from the "gang of four", by their name, usually in Java.
For example, you will find plenty of classes with names like "StuffFactory", implementing the "factory" design pattern, even though you may not need a factory in the first place.
Design patterns still exist, and will always exist, but there I feel there is less of a tendency to use mindlessly use everything from the book.
That's backwards, the point of the GoF book was to document common patterns employed across teams. There was never any intent that you use a design pattern so you can talk about it, that's backwards.
> For example, you will find plenty of classes with names like "StuffFactory", implementing the "factory" design pattern, even though you may not need a factory in the first place.
This assertion makes no sense. A factory is just a function whose responsibility is to instantiate an object. The GoF book then presents two types of factories that fit a specific problem domain.
Is this irrational hatred of design patterns so irrational that even leads people to advocate they do not need to instantiate objects?
You can instantiate objects with a simple "new", you don't always need the extra level of indirection the factory class provides.
Technically, "new" is a factory, but that's not what I mean, what I mean is a class that is named xxxFactory, that has a method that take something as a parameter and returns an object based on some parameter. Or even worse, the xxxFactory is an abstract class for the "real" factory, with names like "Abstract" and "Concrete".
Of course, design patterns are useful, they don't come out of nowhere. And I think it is essential for developers above a certain level to know them, and recognize them by name.
The issue I have with what I called "design pattern fetishism" is that:
- Design patterns are typical solutions to typical problems. What some developers don't get is that if you don't have the problem, you don't need the solution. Most design patterns are about adding levels of indirection "the right way", which is sometimes necessary, but indirection has a cost, in performance, in clarity, and in development effort, don't do it if you don't need to. And I agree that it takes experience to know when you need to, that's why I think abusing design patterns is mostly the result of well meaning, well educated, but inexperienced developers.
- Naming objects with their design pattern sometimes makes sense, but in other cases, I think it is a bit like Hungarian notation. You often end up with bloated names describing how you implemented a solution rather than what the thing really is. Again, not a clear cut thing, and naming things is hard, but I find some correlation between code full of design pattern names and hard to follow code (even though what the code is doing is not that complex).
- Side note: singletons are global variables and shall be treated as such.
I work at a startup with former Amazon engineers in the mid 20's and early 30's.
Never seen so many Helper and Util classes with static methods dangling around. Basically no thought at all given to design patterns.
Design patterns are of course still a thing and very common in core libraries, but majority of the devs I've worked with over the last year (across 3 startups building full stack) would be lost if I started talking about Visitor and Chain of Responsibility.
Design patterns make the most sense after a few requirement changes. Startups don't have that yet and think getting to market is more important than staying in the market for long.
> Design patterns make the most sense after a few requirement changes.
No. Design patterns are higher level programming constructs. The need to use and discuss things in terms of higher level constructs does no arise midway through. Or do backend developers only start to talk about controllers and views and dependency injection and singletons after Product changes their mind on something? Absolutely not.
> Startups don't have that yet and think getting to market is more important than staying in the market for long.
This personal assertion makes no sense at all, and casts doubt on whether you have any idea of what a design pattern is. Your comment reads as a a stream of cliches tied together that have no meaning.
> Design patterns are higher level programming constructs. The need to use and discuss things in terms of higher level constructs does no arise midway through
In part it does. You can hack things up quick without thinking intentionally about higher level constructs and it will all work. When you want to maintain your code for years, then you need to get those constructs in the right place as an intentional act. Sometimes you will put in the right design pattern anyway, but often you won't have them in. Note that this is about the discussion and intentional decision to use patterns. You will of course use design patterns - the difference is getting the right ones in the right place. That takes experience and upfront thinking of a type that startups often do not allow time for.
It may well be correct for a startup to not allow time to think about the right patterns overall. It is a decision that will come to haunt them if all goes well, but they got to market sooner. If thing don't go well (a common case), it was less money spent finding that out.
It's not just the resources we have today, in yesteryear we had the MSDN that had an annual subscription and release, we had more books etc.
Today, there are promotions and aggressive business fighting of formalization within our field. People who slow down and plan out systems have been weeded out of organizations. People who make things and "ship" quickly are rewarded.
This has been the same with quality control in software, and even goes down to bad developers refusing to unit test.
Time to being promoted has shortened as well. Now it's not unusual for a dev to be a senior within 2-3 years. Lead in 5. That's just the start of their career. I haven't heard the last time that the title "Jr" was used.
> Build and learn along the way
It's always been that way but you had a lot more oversight from people that were much more senior.
I hated UML because it felt like someone "very important" had issued a commandment from that unless you did software with UML then you were DOING IT WRONG (spoken in a booming voice from the sky).
It felt super academic and "Thoughtworks"ish and Javaish and made software development boring instead of dynamic and fun.
I'm not sure where this notion of UML diagrams as a silver bullet against technical debt is coming from. The whole OOAD development methodology that UML adoption was predicated on is the opposite of serious or rigorous; you can't just translate domain-level "objects" into a design and expect to end up with something sensible, that's not how it works. (In fact, unless some well-defined part of a system really has meaningful invariants that it cares about and should preserve, there's arguably not much of a real reason to even make an "object" out of it.)
I tend to agree with this. If UML or something UML-like offers value in terms of understandability at some level of abstraction as a substitute for needing to hold the detailed mental model of the entire explicit implementation in one's head, then using it as something extracted from the implementation to provide a simplified sketch of it makes more sense than using it as an input artifact to creating the implementation.
This might be relevant if UML made software easier to survey, review and/or audit. I don't expect this to be the case. (Which is not to say that other plausible solutions don't exist. For instance, an advanced type system often does a good job of surfacing the broad "design" of a piece of software.)
I get that there are worlds where formal methods are useful and excel. In my professional experience, nobody was willing to spend the time to write a formal specification (or much of any specification), because the specifications were subject to change at the whim of a hat.
If there's no specification, there's no way to use formal methods. If there's no specification, producing UML makes even less sense than otherwise. How do you check if the UML matches the desired software? How do you check if the software matches the UML? How do you ensure the changes to the UML propagate to the software and vice versa? How do you examine the changes in the UML? Where are the case studies showing how UML was used successfully?
I considered the explanation was simply that diagrams created in UML are unreadable to lay persons.
Excessive use of visual jargon, and changing standards combine to make everybody a lay person, even those versed in a particular version of UML when confronted with a different version.
Not just forgettable, but vastly different meanings. And these meanings have changed between versions. You really have to get close to the spec to grok what is actually being conveyed.
The devil is in the details - if you have to understand the details like the right arrows for relationship types and visibility modifiers, then it gets much less trivial.
And if you're going to omit those details, then do you really need a standard for your adhoc boxes and arrows diagram?
UML may be dead but I still use sequence diagrams. They're great for visualising complex code and systems, especially if you're new to a system and are trying to gain an understanding the flow of data.
I've used mermaid and plant UML and both seem to powerful enough for my use cases, especially when used in conjunction with the preview mode in VS Code.
Sequence diagrams are great. Any time there's a multi-stage interaction with multiple independent pieces involved, they're hard to beat for communication.
It's not like UML was based on bad ideas. There were just too many cases where the added value was less than the added cost. But when a diagram does add net value it's great to have conventions already.
Entity relationship models are good, but people will disagree whether they are UML.
Sequence diagrams are useful, but the UML version with a vertical diagram with horizontal lines optimizes for the least necessary use cases; also, the UML one has no space for the participants states.
Use cases diagrams are useful, but the UML version just wastes all the space and takes all the useful information out (well, it keeps the actors, could be worse).
Class diagrams aren't very useful at all, and when you need them you don't need the formality that is the main point of UML.
And finally, the UML designers failed to include any data transformation diagram, because they really did only think in procedural terms.
I’m intrigued by the fact that there exists alternatives to UML’s diagrams?
What alternative sequence diagrams are there? Because you are right, we always twist them to include supposedly-orthogonal aspects such as state or actors.
"Alternatives" imply on a formal definition, with strict semantics. IAFAIK, there is no such thing. But most of those kinds of diagram existed before UML, and are designed in very different ways on different contexts.
Specifically for sequence diagrams, it's common to replace those lines with bars where you can annotate the state, and it is common to have actors instead of endpoints defining the bars. But if you are relying too heavily on those two, it may be interesting to look at process diagrams (but not strictly BPMN).
I think statecharts are even more useful than sequence diagrams in documenting behaviour. Statecharts are turing complete, and succinctly visually encode complex behaviour that is going to take reams of text to desribe. Harel et al have done serious, rigourous work in developing statecharts.
> I've used mermaid and plant UML and both seem to powerful enough for my use cases, especially when used in conjunction with the preview mode in VS Code.
I haven’t seen Mermaid, I’ll look it up. PlantUML and the live preview in VSCode is one of my favorite things though, I don’t know how I got along without it when planning hierarchical state machines.
UML is too formal for the quick and dirty world of low profile software projects.
In whiteboard examples, most people tend to come up with their own “dialect” of UML relational graphs anyway. Not to mention the ease of defining skeleton classes.
UML is too trivial to be a standard, feels like a byproduct of the 90s OOP craze.
You're definitely right about that. Most people think of UML as a notation for relationships between components, and it's useful to have a syntax that people can agree on so it's clear what you're drawing on the whiteboard.
But you don't need a 750 page (really) standard creating a formal specification of this syntax.
Just in case people don't know just how formal the specification is, here's part of the explanation of event dispatching:
As discussed in sub clause 13.2.3, a Behavior execution
always has an associated context object (which may be the
execution itself). A context object mediates the handling
of Event occurrences for all of its associated Behavior
executions. When an Event occurrence is recognized by a
context object, it may have an immediate effect or it may
be saved for later triggered effect. An immediate effect
is manifested by direct invocation of a Behavior as determined
by the Event, such as the invocation of the method of a
BehavioralFeature (see sub clause 13.2.3). A triggered effect
is manifested by the storage of the occurrence in the event
pool of the object and the later consumption of the occurrence
by an ongoing Behavior execution that reaches a Trigger that
matches the Event corresponding to the occurrence in the pool
Controversial opinion incoming ... The people who should use UML are too lazy to learn it and instead draw weak abstractions in PowerPoint or C4. Those people are business analysts/requirement engineers/product owners. The true value of UML is that it reduces ambiguity and constrains risk through lightweight prototyping. Wireframes do the same thing. But not one PO can resist writing reams of non descriptive text and drawing impossible data flows. Developers are not the people who should draw UML.
Imagine telling a site construction engineer that not only does he have to manage the construction, but he has to develop the blueprints and also become the office manager once the building is done.
No, UML was not about, nor enabled, lightweight prototyping, the exact opposite. Formal UML as taught and "used" was king of the waterfall and was largely presented as, and definitely taught as, a "design the architecture of your software, then write the code" model. Hence CASE tools - my universities software engineering courses used a product called Together, and Together maintained _live_ updated UML, but the more important (to those teaching UML) feature was that when creating or changing the UML the code would be updated.
People bemoaning the "death" of UML mean the specific and formal standards of notation, many of which were not relevant or even applicable to software.
The general diagramming is still heavily used in software development, and despite their claims I disagree with the author's assertion that everyone uses incompatible notation.
I remember using an IDE which would auto generate these kinds of diagrams and for more than the most basic hello world app, the diagram would be this massive spaghetti where you have to zoom way in to see anything.
Together was a UML-as-code tool, and I never saw how you could deploy a working system using it. We used it for a while, having entire separate 'code' projects to maintain artifacts.
One team tried to use it within their project. Together helpfully would delete a bunch of code when someone decided to start over fresh on a diagram. The lesson Together taught me was, sometimes optimizing/automating part of a process is just a bad idea.
IMHO, UML worked best when you actually built diagrams to show a relationship or part of a process, rather than treating it as some sort of generated view of the system. A full class diagram for any non-trivial system is a bird's nest. A full sequence diagram conveys nothing to the reader that the code itself wouldn't.
There's a reason most repair manuals are illustrated with more than a single exploded view of the full car.
Also - Rational was very much trying to break waterfall by going solidly toward more cyclic processes. It was just geared to be a very formal (but adaptable) model. I would argue that Agile was actually still part of an evolutionary chain from RUP - but 'sold' in an entirely different manner.
> The true value of UML is that it reduces ambiguity and constrains risk through lightweight prototyping.
Nothing in UML is lightweight. As you mentioned there are rules and diagram types to learn.
> Developers are not the people who should draw UML
Maybe not UML but developers should draw more. Diagrams are a great way to communicate architectures, data flow, abstractions, etc. I would save many hours if diagrams where available instead of having to read code.
> The true value of UML is that it reduces ambiguity and constrains risk through lightweight prototyping.
That was certainly not the original premise of UML. Booch et al came up with a grand idea «once you have UML, you will never have to write the code again and our tools (Rational Software) will generate your applications for you from the UML diagrams where everything is an object».
UML took ages in evolution and development, it was a collection of seemingly unrelated (or loosely related at best) diagramming approaches that, in practice, was rarely used in its entirety due to:
1. Being incomplete or lacking altogether in early stages of its evolution;
2. Being very heavy-weight and prohibitevely expensive tools (Rational Rose, doh!) from one vendor;
3. Generated code was bloated at best or did not work at worst and required substantial amounts of manual fixing up.
Most importantly, UML was initially focused on interactions taking place within a single isolated system whereas the industry had already started moving towards a distributed application interaction model.
There are a few useful parts in the UML universe, though. Sequence and ER diagrams are useful today, class diagrams can have some occasional limited value – to understand legacy frameworks and systems but are nearly never appropriate for describing new data models. Component diagrams are generally useful but almost no-one can read and understand them anymore. And cross-system, end-to-end business process view centric, interactions are much easier to represent with simple, BPMN-style, swimlane diagrams – the business crowd also finds them easy to read and comprehend.
Ha, an interesting link, thanks. It comes off as an attempt to atone for former sins and a rather not very convincing one (not to me, personally, anyway).
Booch goes on to state:
> The UML was originally designed to be a language for visualizing and reasoning about a system […]
Which system, an existing one or the one being designed? Most existing systems don't have the extensive UML diagramming that supplements the system documentation, so if we are going to use UML to reverse engineer an existing system, the UML diagrams are nearly guaranteed to be incomplete and miss a crucial aspect of the system or a few. Booch actually confesses in being a reverse engineering aficionado:
> I have always been a fan of reverse engineering notation from code.
If we are using UML to reason about a system being designed, the UML diagramming and coding are disjoint activities undertaken by distinct people: architects or designers produce UML diagrams and software engineers interpret them. The interpretation is always a subjective affair and is nearly guaranteed to diverge from the diagrams at some point. Booch goes on to attest the same further down the thread:
> The code is the truth, but not the whole truth.
So, Rational Software had Rational Rose that generated the code from UML diagrams in an attempt to bridge the gap (but not as an attempt to be a visual programming language) between the design in UML and the interpretation of the design by a human being, and that did not work.
> Ernesto Garbarino says that UML was killed by decreasing standards among programmers: “Agile was the assassin and user stories were her deadly, poisonous arrow heads (pun intended).”
I got my start in a shop whose CTO was a big believer in UML. I can tell you unequivocally that software processes from that era, while providing some useful lessons, were a result of the 90s software engineering Zeitgeist, which included these major aspects:
1) Non-technical management was still regularly involved in the management of software engineering and engineers needed to explain “Here’s how we will do X” to laypersons
2) Object Oriented programming was at the peak of its hype cycle, but most of the software development workforce had a superficial understanding of it at best. UML allowed you to explore a problem in an object oriented manner before writing any code and gave more OO-savvy engineers the ability to communicate these concepts to other developers who had no hands-on experience writing object oriented code.
3) The “style” of object oriented programming advocated back then would probably get your hand slapped during any modern code review… even by relatively junior developers.
4) Lots of software development practices we take for granted today were not universal: source control, fast build turn-arounds, automated testing. Likewise, because software was delivered via physical media and your ability to distribute patches was far more challenging the whole process was fundamentally more conservative.
So to bring this full circle, what changed since UML’s heyday?
1) Software engineering as an institution matured to the point where almost the entire management chain will typically know not just how to code but actually ship software (seed stage startups are an exception here)
2) Object Oriented programming hype has died down. It turns out it wasn’t the productivity boon we imagined (garbage collection and open source libraries did more for us)
3) Stronger and more robust type systems, Functional programming concepts, and unit testing methodologies are used to mitigate defects
4) Turn-around time to distribute a fix for a production defect is measured in minutes or hours - not weeks or months.
5) Things like CI/CD exist which would’ve made a 90s developers head spin.
I agree that there is a clear upwards trajectory for improvements. When I was a teenager in 1964, I had access to a teletype hooked up to a remote server on the east coast that supported BASIC. I used punched cards at my first real job, although they later bought me a Xerox 1108 Lisp Machine. After the Lisp Machine I felt like things sort of went down hill. I love git compared to cvs and svn. I don’t like using Jira unless there is someone dedicated and skilled at relieving developers of some of the Agile cruft. I love cloud platforms like GCP, AWS, and Azure. I like continuous integration, Kubernetes, etc., if someone else sets everything up (+1000 for having skilled dev ops people on a team).
1 may be true at some companies, but it’s by far not the case for the great majority of software companies. Furthermore, while it’s nice if managers are broadly familiar with software engineering, it doesn’t bring any benefits for them to code or ship software. On the contrary, they’re more likely to annoy the actual people doing those tasks.
And while the hype for 2 may have died down, it did so because OOP became the mainstream. Which means that more documentation not less is needed.
3 is not related to UML. UML is a design and documentation language, it’s not pertinent to mitigating defects.
4 is also inapplicable. UML is once again not a QA technique.
5 is also inapplicable for the same reasons as above.
Honestly it looks like you listed more or less five random things which changed since UML’s heyday…
Some UML diagrams are still super useful. The real problem is that the parts of the ecosystem is over engineered and targeted to the wrong audience.
For example, Class diagrams, sequence diagrams -> useful for debugging or for implementation, but very bad for product specifications. If the Product person could write class diagrams, they could probably just implement the system themselves. On the other hand, if a programmer was given a class diagram, they'd still need to figure out if the design/diagram was correct to solve the problem they're given.
On the other hand, a couple of market-tecture (architecture/systems diagram but made easy to understand to even sales people) was drawn, with some useful descriptions of what the whole system did, people/teams can be assigned to fill out the details, and measure their performance against the constrained problem.
[Rant] The class in university I hate the most is "Software Engineering" because it doesn't sound like engineering at all. They taught UML, Waterfall, Sequence, ER Diagram, and all useless stuff that I never use within 10 years in software industry.
Sequence diagrams are very useful for APIs and understanding protocols between systems.
ER diagrams are great for presenting a database schema (just don't get too hung up the exact arrow you're using!) When I start a new major project, one of the first things I do is an ERD. You don't need every field (column, attribute...), but the tables (entities, objects, collections, whatever you want to call it...) and their relationships are pretty important.
Yes but it seems the order is taught is important. Without actual industry experience, it never occurred to me it could be useful.
After some years working, it's clear it's useful in some capacity but it's easy to overdo it (like require every detail of the system to be in those formats) or misuse it (sequence diagram improperly documenting async flows).
I think statecharts are even more useful than sequence diagrams in documenting behaviour. Statecharts are Turing complete, and succinctly visually encode complex behaviour that is going to take reams of text to describe. Harel et al have done serious, rigourous work in developing statechart.
I would like to offer the dissenting opinion that it's good to send cs students out into the world with the idea that "software planning, management and communication exists, and there are a variety of approaches to it" - even if what's actually used is not taught (partly because good approaches are a genuine commercial advantage and things change fast).
If anything it would be great to see more emphasis on this, most engineers I know spend as much time planning, communicating, organising and reporting on work as they do sitting in front of an IDE.
Also, everyone I know uses sequence diagrams and ER diagrams fairly often when things get too complicated for handwaving.
I find some aspects of UML, mainly sequence diagrams, useful. Other aspects, like class diagrams, not so much. Plain old boxes-and-line drawings are usually enough.
UML was associated with big upfront design, and basically died with "Agile." Why design anything when you can fix it in the next sprint?
I find many software engineers, including myself, have a hard time communicating coherently and specifically the detail of their plans, in my years as a SWE in the fun-startup-space I've enjoyed working. There are ambiguities embedded in many design challenges, and they interfere with
UML has been a great way to talk about parameters, data flow, and ownership. I use it for bits and bobs of the conversation, and to help break down problems for distributing the work amongst team members. I don't pre-plan entire projects with UML, though that could be influenced more by business-requirements than the pros and cons of UML.
Good article, nails a lot of stuff. Before UML, Grady Booch sent me a rough manuscript of his future book Object-Oriented Analysis and Design. I used his diagram style in a C++ book I wrote for McGraw-Hill (I don’t think my book was very good, in retrospect, but the diagrams were nice).
A few years later I co-wrote a UML for Java Developers book. Then for years at work I just sparingly used my favorite Sequence Diagrams and a few Class Diagrams - nothing else. In the last 20 years I have just used Sequence Diagrams, and I still like those.
Pardon something off-topic, but I would appreciate opinions on this: since we are talking about tidy old fashioned practices vs. agile development, I used to hate full on code reviews, but I enjoyed and thought the lighter weight practice of code walkthroughs or even just having two people read through a code module and fill in a questions form. The author(s) answer the questions, everyone talks a bit, and in the end, reviewing a perhaps 500 line module might take up a total of 3 hours of engineering time - and more people understand more of the system that they are working on if this is done frequently with many combinations of people.
I think the issues with UML and any technique of top/down design is that it doesn't recognize the bidirectional influence of design.
The interface influences the implementation and the implementation details influences the interface.
Similarly, the whole influences the unit, and the unit influences the whole.
You can only design working software if it takes into account both directions, software design has to simultaneously take into account top/down and bottom/up concerns.
I think people realized this, and so when you start, it makes more sense to only have a rough top/down draft of the design, since once you implement you'll need to refactor the design anyways from the concerns that appeared from the implementation details.
UML therefore became a waste of time, since half of it would change anyways by the time the project shipped.
I worked briefly for a place that generated code from UML. The code itself was ugly C++, but I never looked at it so who cares. Every week the first thing I did was print out the UML on large paper and paste it on my wall. It was nice to see everything on my wall like that, but just one week of one programmer time and what was on the wall was already obsolete in some critical way.
One important part of UML is the layout. Every week I.made a minor tweak to how the boxes were on the page so things looked nice. Every few months a larger change to layout.
Since then I've been to a lot of places where people ask for UML, but since there is no way to synchronize the code and UML the UML is left to rot. We could keep it up to date and i'd love it, but that means one full time graphical person for every two developers. I don't think UML is worth it unless it is the code.
I still find it helpful to use UML diagrams in a classroom setting when describing a project codebase at a high level. For example, this slide diagrams some classes used in a Scheme interpreter:
https://inst.eecs.berkeley.edu/~cs61a/sp22/assets/slides/30-...
(Generated with PynSource)
I also find such diagrams useful in an engineering setting when explaining a codebase or design decision to teammates.
Would a short description of UML at top hurt. Here I am trying to figure out how thid related to user mode linux. I stopped mid way and had to read comments.
Either way, didn't know UML died, visio still supports it right?
Same. User Mode Linux was my guess; the first paragragh of the article was enought to tell me that was wrong but gave no hint of what the acronym might mean, not even broadly.
I had to google : it is actually about Unified Modeling Language diagrams of object classes and their relationships. I guess nobody who uses UML diagrams ever thinks of UML as an acronym?
Seconded! You can have my PlantUML when you pry it from my cold, dead hands. Once I was shown diagram source you can diff between revisions, I was sold.
I use ER diagrams, Sequence diagrams, State machines, Use case diagrams etc during planning design stages and find it really helpful to capture business processes / requirements and turn those down to a rough design. Except trivial cases (of which I admit we have plenty) thinking before piling up code has great value.
What did die is insane approach preached by fanatics in Rational. Now we have the same situation with Agile / SCRUM. I hope this abomination (the way it is being forced down everyone's throat) suffer the same fate. The other related subjects are / were - everything has to be, OOP, OOP sucks, let everything be pure functions and other crap like this.
Luckily I've avoided all the propaganda and sticking to "the only true religion" never mind that new new one would come out every other year
128 comments
[ 7.5 ms ] story [ 249 ms ] threadI think that this is also part of the reason why there has been a shift away from design patterns (e.g. Gang of Four, Patterns of Enterprise Application Architecture): the training that it required to be a proficient software engineer 20 years ago isn't the same as it is now.
No StackOverflow, no YouTube, a lot of documentation still on paper, etc.
So you'd get a CS degree, read, learn, and apply the knowledge.
That formula has inverted.
Nowadays, you can build and learn along the way. Watch a tutorial and learn "just-in-time". But this also means that there's really no reason to get into complex topics like modeling, "formal" diagramming, and even design patterns.
There is no such shift. Design patterns are ubiquitous and more popular than ever. Some frameworks explicitly base their added value on providing a specific design pattern.
A design pattern is a higher level construct. It makes absolutely no sense to claim that there's a shift away from higher level constructs when the whole point of programming is using a lower-level programming language to implement higher-level abstractions that implement our requirements.
For example, you will find plenty of classes with names like "StuffFactory", implementing the "factory" design pattern, even though you may not need a factory in the first place.
Design patterns still exist, and will always exist, but there I feel there is less of a tendency to use mindlessly use everything from the book.
This assertion makes no sense. A factory is just a function whose responsibility is to instantiate an object. The GoF book then presents two types of factories that fit a specific problem domain.
Is this irrational hatred of design patterns so irrational that even leads people to advocate they do not need to instantiate objects?
Technically, "new" is a factory, but that's not what I mean, what I mean is a class that is named xxxFactory, that has a method that take something as a parameter and returns an object based on some parameter. Or even worse, the xxxFactory is an abstract class for the "real" factory, with names like "Abstract" and "Concrete".
Of course, design patterns are useful, they don't come out of nowhere. And I think it is essential for developers above a certain level to know them, and recognize them by name.
The issue I have with what I called "design pattern fetishism" is that:
- Design patterns are typical solutions to typical problems. What some developers don't get is that if you don't have the problem, you don't need the solution. Most design patterns are about adding levels of indirection "the right way", which is sometimes necessary, but indirection has a cost, in performance, in clarity, and in development effort, don't do it if you don't need to. And I agree that it takes experience to know when you need to, that's why I think abusing design patterns is mostly the result of well meaning, well educated, but inexperienced developers.
- Naming objects with their design pattern sometimes makes sense, but in other cases, I think it is a bit like Hungarian notation. You often end up with bloated names describing how you implemented a solution rather than what the thing really is. Again, not a clear cut thing, and naming things is hard, but I find some correlation between code full of design pattern names and hard to follow code (even though what the code is doing is not that complex).
- Side note: singletons are global variables and shall be treated as such.
Never seen so many Helper and Util classes with static methods dangling around. Basically no thought at all given to design patterns.
Design patterns are of course still a thing and very common in core libraries, but majority of the devs I've worked with over the last year (across 3 startups building full stack) would be lost if I started talking about Visitor and Chain of Responsibility.
No. Design patterns are higher level programming constructs. The need to use and discuss things in terms of higher level constructs does no arise midway through. Or do backend developers only start to talk about controllers and views and dependency injection and singletons after Product changes their mind on something? Absolutely not.
> Startups don't have that yet and think getting to market is more important than staying in the market for long.
This personal assertion makes no sense at all, and casts doubt on whether you have any idea of what a design pattern is. Your comment reads as a a stream of cliches tied together that have no meaning.
In part it does. You can hack things up quick without thinking intentionally about higher level constructs and it will all work. When you want to maintain your code for years, then you need to get those constructs in the right place as an intentional act. Sometimes you will put in the right design pattern anyway, but often you won't have them in. Note that this is about the discussion and intentional decision to use patterns. You will of course use design patterns - the difference is getting the right ones in the right place. That takes experience and upfront thinking of a type that startups often do not allow time for.
It may well be correct for a startup to not allow time to think about the right patterns overall. It is a decision that will come to haunt them if all goes well, but they got to market sooner. If thing don't go well (a common case), it was less money spent finding that out.
Today, there are promotions and aggressive business fighting of formalization within our field. People who slow down and plan out systems have been weeded out of organizations. People who make things and "ship" quickly are rewarded.
This has been the same with quality control in software, and even goes down to bad developers refusing to unit test.
Time to being promoted has shortened as well. Now it's not unusual for a dev to be a senior within 2-3 years. Lead in 5. That's just the start of their career. I haven't heard the last time that the title "Jr" was used.
> Build and learn along the way
It's always been that way but you had a lot more oversight from people that were much more senior.
Citation needed.
I see, use and teach design patterns every day, and I work with Data Scientists.
> That formula has inverted.
> Nowadays, you can build and learn along the way.
People's opinions by now differ byt a huge amount whether this is a good or bad/dangerous trend.
https://www.theonion.com/sun-chips-abandons-biodegradable-ba...
"Are you kidding me? I crafted my entire freshman year persona around being the 'Sun Chips Asshole.'"
PAUL KENEMORE • STUDENT
https://news.ycombinator.com/item?id=26956298
Also interesting is the linked post:
https://news.ycombinator.com/item?id=26934577
It felt super academic and "Thoughtworks"ish and Javaish and made software development boring instead of dynamic and fun.
Glad its gone.
If there's no specification, there's no way to use formal methods. If there's no specification, producing UML makes even less sense than otherwise. How do you check if the UML matches the desired software? How do you check if the software matches the UML? How do you ensure the changes to the UML propagate to the software and vice versa? How do you examine the changes in the UML? Where are the case studies showing how UML was used successfully?
And what are you going to do, ask during the interview if the company uses UML? I mean who doesn’t use a little UML in a mid to big software company?
Seems safer just to accept that one will come in contact with it and prepare for that day. I use it to document designs quite a lot myself.
Excessive use of visual jargon, and changing standards combine to make everybody a lay person, even those versed in a particular version of UML when confronted with a different version.
And if you're going to omit those details, then do you really need a standard for your adhoc boxes and arrows diagram?
Use-case diagrams should be used more.
Class diagrams are good to reveal poor OOP designs.
I've used mermaid and plant UML and both seem to powerful enough for my use cases, especially when used in conjunction with the preview mode in VS Code.
It's not like UML was based on bad ideas. There were just too many cases where the added value was less than the added cost. But when a diagram does add net value it's great to have conventions already.
If UML tooling had just focused on diagrams, I would not revile UML.
Sequence diagrams are useful, but the UML version with a vertical diagram with horizontal lines optimizes for the least necessary use cases; also, the UML one has no space for the participants states.
Use cases diagrams are useful, but the UML version just wastes all the space and takes all the useful information out (well, it keeps the actors, could be worse).
Class diagrams aren't very useful at all, and when you need them you don't need the formality that is the main point of UML.
And finally, the UML designers failed to include any data transformation diagram, because they really did only think in procedural terms.
What alternative sequence diagrams are there? Because you are right, we always twist them to include supposedly-orthogonal aspects such as state or actors.
Specifically for sequence diagrams, it's common to replace those lines with bars where you can annotate the state, and it is common to have actors instead of endpoints defining the bars. But if you are relying too heavily on those two, it may be interesting to look at process diagrams (but not strictly BPMN).
I haven’t seen Mermaid, I’ll look it up. PlantUML and the live preview in VSCode is one of my favorite things though, I don’t know how I got along without it when planning hierarchical state machines.
In whiteboard examples, most people tend to come up with their own “dialect” of UML relational graphs anyway. Not to mention the ease of defining skeleton classes.
UML is too trivial to be a standard, feels like a byproduct of the 90s OOP craze.
As long as it gets the point across, who cares?
But you don't need a 750 page (really) standard creating a formal specification of this syntax.
Just in case people don't know just how formal the specification is, here's part of the explanation of event dispatching:
> Imagine telling a site construction engineer that not only does he have to manage the construction, but he has to develop the blueprints...
Okay.
But yeah I feel the office manager bit, that hits close to home.
What about for interpreted languages?
People bemoaning the "death" of UML mean the specific and formal standards of notation, many of which were not relevant or even applicable to software.
The general diagramming is still heavily used in software development, and despite their claims I disagree with the author's assertion that everyone uses incompatible notation.
One team tried to use it within their project. Together helpfully would delete a bunch of code when someone decided to start over fresh on a diagram. The lesson Together taught me was, sometimes optimizing/automating part of a process is just a bad idea.
IMHO, UML worked best when you actually built diagrams to show a relationship or part of a process, rather than treating it as some sort of generated view of the system. A full class diagram for any non-trivial system is a bird's nest. A full sequence diagram conveys nothing to the reader that the code itself wouldn't.
There's a reason most repair manuals are illustrated with more than a single exploded view of the full car.
Also - Rational was very much trying to break waterfall by going solidly toward more cyclic processes. It was just geared to be a very formal (but adaptable) model. I would argue that Agile was actually still part of an evolutionary chain from RUP - but 'sold' in an entirely different manner.
Nothing in UML is lightweight. As you mentioned there are rules and diagram types to learn.
> Developers are not the people who should draw UML
Maybe not UML but developers should draw more. Diagrams are a great way to communicate architectures, data flow, abstractions, etc. I would save many hours if diagrams where available instead of having to read code.
That was certainly not the original premise of UML. Booch et al came up with a grand idea «once you have UML, you will never have to write the code again and our tools (Rational Software) will generate your applications for you from the UML diagrams where everything is an object».
UML took ages in evolution and development, it was a collection of seemingly unrelated (or loosely related at best) diagramming approaches that, in practice, was rarely used in its entirety due to:
Most importantly, UML was initially focused on interactions taking place within a single isolated system whereas the industry had already started moving towards a distributed application interaction model.There are a few useful parts in the UML universe, though. Sequence and ER diagrams are useful today, class diagrams can have some occasional limited value – to understand legacy frameworks and systems but are nearly never appropriate for describing new data models. Component diagrams are generally useful but almost no-one can read and understand them anymore. And cross-system, end-to-end business process view centric, interactions are much easier to represent with simple, BPMN-style, swimlane diagrams – the business crowd also finds them easy to read and comprehend.
UML, as a whole, was moribund from the beginning.
Booch goes on to state:
> The UML was originally designed to be a language for visualizing and reasoning about a system […]
Which system, an existing one or the one being designed? Most existing systems don't have the extensive UML diagramming that supplements the system documentation, so if we are going to use UML to reverse engineer an existing system, the UML diagrams are nearly guaranteed to be incomplete and miss a crucial aspect of the system or a few. Booch actually confesses in being a reverse engineering aficionado:
> I have always been a fan of reverse engineering notation from code.
If we are using UML to reason about a system being designed, the UML diagramming and coding are disjoint activities undertaken by distinct people: architects or designers produce UML diagrams and software engineers interpret them. The interpretation is always a subjective affair and is nearly guaranteed to diverge from the diagrams at some point. Booch goes on to attest the same further down the thread:
> The code is the truth, but not the whole truth.
So, Rational Software had Rational Rose that generated the code from UML diagrams in an attempt to bridge the gap (but not as an attempt to be a visual programming language) between the design in UML and the interpretation of the design by a human being, and that did not work.
I got my start in a shop whose CTO was a big believer in UML. I can tell you unequivocally that software processes from that era, while providing some useful lessons, were a result of the 90s software engineering Zeitgeist, which included these major aspects:
1) Non-technical management was still regularly involved in the management of software engineering and engineers needed to explain “Here’s how we will do X” to laypersons
2) Object Oriented programming was at the peak of its hype cycle, but most of the software development workforce had a superficial understanding of it at best. UML allowed you to explore a problem in an object oriented manner before writing any code and gave more OO-savvy engineers the ability to communicate these concepts to other developers who had no hands-on experience writing object oriented code.
3) The “style” of object oriented programming advocated back then would probably get your hand slapped during any modern code review… even by relatively junior developers.
4) Lots of software development practices we take for granted today were not universal: source control, fast build turn-arounds, automated testing. Likewise, because software was delivered via physical media and your ability to distribute patches was far more challenging the whole process was fundamentally more conservative.
So to bring this full circle, what changed since UML’s heyday?
1) Software engineering as an institution matured to the point where almost the entire management chain will typically know not just how to code but actually ship software (seed stage startups are an exception here)
2) Object Oriented programming hype has died down. It turns out it wasn’t the productivity boon we imagined (garbage collection and open source libraries did more for us)
3) Stronger and more robust type systems, Functional programming concepts, and unit testing methodologies are used to mitigate defects
4) Turn-around time to distribute a fix for a production defect is measured in minutes or hours - not weeks or months.
5) Things like CI/CD exist which would’ve made a 90s developers head spin.
Other developers who never wrote object oriented code.
And while the hype for 2 may have died down, it did so because OOP became the mainstream. Which means that more documentation not less is needed.
3 is not related to UML. UML is a design and documentation language, it’s not pertinent to mitigating defects.
4 is also inapplicable. UML is once again not a QA technique.
5 is also inapplicable for the same reasons as above.
Honestly it looks like you listed more or less five random things which changed since UML’s heyday…
For example, Class diagrams, sequence diagrams -> useful for debugging or for implementation, but very bad for product specifications. If the Product person could write class diagrams, they could probably just implement the system themselves. On the other hand, if a programmer was given a class diagram, they'd still need to figure out if the design/diagram was correct to solve the problem they're given.
On the other hand, a couple of market-tecture (architecture/systems diagram but made easy to understand to even sales people) was drawn, with some useful descriptions of what the whole system did, people/teams can be assigned to fill out the details, and measure their performance against the constrained problem.
ER diagrams are great for presenting a database schema (just don't get too hung up the exact arrow you're using!) When I start a new major project, one of the first things I do is an ERD. You don't need every field (column, attribute...), but the tables (entities, objects, collections, whatever you want to call it...) and their relationships are pretty important.
After some years working, it's clear it's useful in some capacity but it's easy to overdo it (like require every detail of the system to be in those formats) or misuse it (sequence diagram improperly documenting async flows).
I find it's easier to think of these data as cartesian product of a bunch of tuple. Even having table in my imagination is confusing!
If anything it would be great to see more emphasis on this, most engineers I know spend as much time planning, communicating, organising and reporting on work as they do sitting in front of an IDE.
Also, everyone I know uses sequence diagrams and ER diagrams fairly often when things get too complicated for handwaving.
I too used boolean algebra simplifications for refactoring legacy code base that had lots of nightmare if/else once.
They seem like a tool to fix mistake that shouldn't be there in the first place with otherwise methods.
I don't mind if the class called like "Software Project Planing"
UML was associated with big upfront design, and basically died with "Agile." Why design anything when you can fix it in the next sprint?
I find many software engineers, including myself, have a hard time communicating coherently and specifically the detail of their plans, in my years as a SWE in the fun-startup-space I've enjoyed working. There are ambiguities embedded in many design challenges, and they interfere with
UML has been a great way to talk about parameters, data flow, and ownership. I use it for bits and bobs of the conversation, and to help break down problems for distributing the work amongst team members. I don't pre-plan entire projects with UML, though that could be influenced more by business-requirements than the pros and cons of UML.
A few years later I co-wrote a UML for Java Developers book. Then for years at work I just sparingly used my favorite Sequence Diagrams and a few Class Diagrams - nothing else. In the last 20 years I have just used Sequence Diagrams, and I still like those.
Pardon something off-topic, but I would appreciate opinions on this: since we are talking about tidy old fashioned practices vs. agile development, I used to hate full on code reviews, but I enjoyed and thought the lighter weight practice of code walkthroughs or even just having two people read through a code module and fill in a questions form. The author(s) answer the questions, everyone talks a bit, and in the end, reviewing a perhaps 500 line module might take up a total of 3 hours of engineering time - and more people understand more of the system that they are working on if this is done frequently with many combinations of people.
The interface influences the implementation and the implementation details influences the interface.
Similarly, the whole influences the unit, and the unit influences the whole.
You can only design working software if it takes into account both directions, software design has to simultaneously take into account top/down and bottom/up concerns.
I think people realized this, and so when you start, it makes more sense to only have a rough top/down draft of the design, since once you implement you'll need to refactor the design anyways from the concerns that appeared from the implementation details.
UML therefore became a waste of time, since half of it would change anyways by the time the project shipped.
It still happens today without UML, it's just moved from flow diagrams to powerpoint and word presentations.
One important part of UML is the layout. Every week I.made a minor tweak to how the boxes were on the page so things looked nice. Every few months a larger change to layout.
Since then I've been to a lot of places where people ask for UML, but since there is no way to synchronize the code and UML the UML is left to rot. We could keep it up to date and i'd love it, but that means one full time graphical person for every two developers. I don't think UML is worth it unless it is the code.
I also find such diagrams useful in an engineering setting when explaining a codebase or design decision to teammates.
Either way, didn't know UML died, visio still supports it right?
I had to google : it is actually about Unified Modeling Language diagrams of object classes and their relationships. I guess nobody who uses UML diagrams ever thinks of UML as an acronym?
Edit: shoutout to https://plantuml.com/ for making me the coolest kid on any new team.
What did die is insane approach preached by fanatics in Rational. Now we have the same situation with Agile / SCRUM. I hope this abomination (the way it is being forced down everyone's throat) suffer the same fate. The other related subjects are / were - everything has to be, OOP, OOP sucks, let everything be pure functions and other crap like this.
Luckily I've avoided all the propaganda and sticking to "the only true religion" never mind that new new one would come out every other year