Has UML died without anyone noticing?
garba.org
garba.org
The model driven thing was nice but it was never good enough to actually help with code. It was also deeply rooted in the crippled Java days so full of verbose diagram representing overly verbose classes.
To hyperbole a bit, I'd rather spend time writing property based tests and a few types in haskell in a way.
I'd rather spend some time making sure I'm building the right thing, rather than testing that what I built correctly does the wrong thing.
On the other hand, if you want to argue that UML is not the optimal way to do that, you could make a case. It makes you think through some questions, but those may not be the only questions, and there may be other ways of thinking through those areas than drawing diagrams.
And if you want to iterate your designs, UML is a painful way to do so. You'd want to design in some other medium that is easier to change. (Maybe something text based?) But if you're thinking through all the design issues in another medium, and iterating the design in that other medium, then why produce the UML at the end? To communicate the design to other people - that's the point of UML. But if you can communicate the design better using something else (like maybe the medium you actually design in), then why produce the UML?
The good UML diagrams are sequence and maybe use case.
> I'd rather spend some time making sure I'm building the right thing, rather than testing that what I built correctly does the wrong thing.
I don't believe the GP was saying to use tests instead of planning. They were saying to use the tests as planning.
They called out property-based testing in which you describe behavior of the system as a set of rules, such as `f(x) % 2 == 0`, and the test harness tests many inputs trying to find the simplest example that fails that criteria.
They also called out defining types (in their chosen language, not a step removed in a UML diagram), which allows you to think about how the data is shaped before you write an implementation that forces a shape.
In my 25ish years of experience writing code? That has happened for a non trivial task exactly zero times.
If the idea is you could refactor the UML (and hence generated code) to adjust, since none of the tools are able to generate functional code (stubs and simple templates yes, but not much more than that), that means it would need to refactor a bunch of human manipulated and generated code without breaking it. Which I think is well beyond even our current capabilities.
Writing code is very close to what 90% of the drafting work is for construction (aka some relatively junior person figuring out exactly how many bricks would fit in this space, and how thick it would need to be, to meet the requirements his senior person told him he had to meet - and trying a couple other options when that is obviously BS that doesn’t work the first few times, and then everyone refactoring things when it turns out the first idea causes too many issues and the architect’s grand plan for a 50 ft open span in an area is impossible with current materials).
Software developers are able to build abstractions out of thin air and put them out into the world incredibly quickly. The value proposition of some of these abstractions are big enough that it enables _other_ value propositions. The result of that is that our "materials" are often new, poorly documented, and poorly understood. Certainly my experience writing software is that I am asked to interact with large abstractions that are only a few years old.
Conversely, when I sit in a meeting with a bunch of very senior mechanical engineers every one of them has memorized all of the relevant properties of every building material they might want to use for some project: steel, concrete, etc. Because it's so static, knowing them is table stakes.
I'd say this difference in changing "materials" is a big source of this discrepancy.
The big difference is no one really tries new things that often in construction, because for the most part people have enough difficulty just making the normal run of the mill stuff work - and people who have the energy to try often end up in jail or bankrupt.
In Software, we’re so young we end up doing mostly new things all the time. Our problems are simple enough and bend to logic enough too, that we usually get away with it.
If you’ve ever poured a footing for a building, then had the slump test fail on the concrete afterwards you’ll sorely be wishing for a mere refactoring of a JavaScript spaghetti codebase under a deadline.
Buildings neither are Turing complete, nor do the building blocks become obsolete every few years.
The closest analogue to software development is legislation.
Even the best written rules can have unintended consequences, and so we have tools to make the behavior ever more precise and less error-probe. But it’s never fool proof.
Also and like legislation, it’s the edge cases that balloon a proof of concept into monstrous sizes.
In some respects, for software to advance some components need to be less powerful. But we have this fetish for inventing yet another Turing complete language in the pro space, just because, and bolting on a million features.
It’s unnecessarily tiresome.
They’re also using literally thousands of years of deeply ingrained cultural rules and expectations focusing on making living in and building structures effective (it’s one of the core tenets of civilization afterall), supported by an army of inspectors, design specialists, contractors (themselves leveraging thousands of years of passed down and deeply baked in expertise in everything from bricklaying, to concrete work, to framing).
All that for what, functionally, is a box we put things in, including ourselves, that we prefer provides some basic services to a decent standard and isn’t too ugly.
You'd design and build a building, and that was it. If the roof leaked (common on building-like pieces of art), you didn't want to know about it. If the interior was changed to actually work for the buildings occupants, you didn't want to know -- that'd mean that your beautiful design has been marred.
All this suggests to me that some of these designs are done without deeply considering the needs of the people affected, and realizing that those needs change, and worse, without learning from the mistakes and successes of the past.
[Note that I am not arguing about the merits of how software is, was, or should be designed.]
The goal of 3d printing and the like is to make mechanical engineering more like software so you can get a tight iteration loop
If architects could build a house multiple times a day while slightly rearranging the layout every time they'd do that in a heartbeat.
There are natural-intelligence (human) agents translating the diagram to "code" (bricks).
There is a lot of problem fixing going on done by the construction crews, cursing at the architects (sometimes, or just going with the flow and what comes with the job).
That is the same with software:
If you give good developers diagrams those human agents too will be able to produce useful software from it, no matter the flaws in the diagrams, as long as they understand the intent and are motivated to solve the problems.
More modern systems like LuaJIT, SpiderMonkey, and HotSpot are even more radical, constantly tearing down and rebuilding parts of the machine code while the program is running. Programs built with them are more like living things than buildings, with osteoclasts constantly digesting bones while osteoblasts build them. In these systems we just send the plans—our source code, or a sparser form of it—to the end-user to be gardened and nurtured. Then, just as osteoblasts build denser bone where its strength is most needed, the JIT builds higher-performance code for the cases that automatic profiling shows are most performance-critical to that user.
— ⁂ —
Soon architects will be able to do their work in the same way.
Like Microsoft programmers in the 01990s, they'll do a "nightly build" of the current design with a swarm of IoT 3-D printers. Consider the 10,000 tonnes of structural steel that make up the Walt Disney Concert Hall in Los Angeles, which seats 2265 people. After the 16-year construction project, it was discovered that reflection from the concave surface was creating deadly hot spots on the sidewalk and nearby condos, requiring some expensive rework.
If each assembler can bolt a kilogram of steel onto the growing structure every 8 seconds, then 2000 assemblers can rebuild it from source in a bit over 11 hours. In the morning, like programmers, the architects can walk through the structure, swing wrecking balls at it to verify their structural integrity calculations, and see how the light falls, and, importantly, notice the sidewalk hotspots. Perhaps another 2000 printers using other materials can add acoustic panels and glazing, so the architects can see how the acoustics of the space work. Perhaps they can try out smaller changes while inside the space using a direct-manipulation interface, changing the thickness of a wall or the angle of an overhang, while being careful not to stand underneath.
In the afternoon, when the architects have gone home, the assemblers begin the work of garbage collection of the parts of the structure whose design has been changed, so the next nightly build reflects the latest updates. As night falls, they begin to rebuild. The build engineer sings softly to them by the moonlight, alert for signs of trouble that could stall the build.
— ⁂ —
Today that isn't practical—the nightly build machine for a single architectural firm would cost several billion dollars. But that machinery itself will come down in cost as we learn to bring the exuberant living abundance of software to other engineering disciplines.
To do ten "load builds" in the 16 years the Walt Disney Concert Hall took, you'd only need two assemblers, perhaps costing a couple million dollars at today's prices; they'd be able to complete each successive prototype building in 15 months.
Suppose prices come down and you can afford 32 assemblers, each placing a kilogram of steel every 8 seconds. Now you can do a "monthly build", which is roughly what I did when I joined a C++ project in 01996 as the build engineer. Or you can build 10:1 reduced scale models (big enough to fit 22 people, in this case) a thousand times as fast. Incremental recompilation on the C++ project allowed individual developers to test their incremental changes to the design, and similarly this kind of automation could allow individual architects to test their incremental changes to the building, though perhaps not all at the same time—the full-scale building would be like an "integration test server".
Suppose prices come down further and you can afford 512 such assemblers. Now you're not quite to the point of being able to do nightly builds, but you can do a couple of builds a week, and you can rebuild a fourth of the Walt Disney Concert Hall overnight.
Suppose prices come down further and you can afford 8192 assemblers. Now you can rebuild the building several times a day. You can totally remodel the concert hall between the morning concert and the afternoon concert.
Suppose prices come down further and you can afford 131072 assemblers. Now you can rebuild the concert hall in 10 minutes. There's no longer any need to leave it built; you can set it up in a park on a whim for a concert, or remodel it into a cruise ship.
Suppose prices come down further and you can afford 2097152 assemblers. Now totally rebuilding the concert hall takes about 30 seconds, and you can adapt it dynamically to the desires and practices of whoever is using it at the moment. This is where modern software development practice is: my browser spends 30 seconds recompiling Fecebutt's UI with SpiderMonkey every time I open the damn page. At this point the "assemblers" are the concert hall; they weigh 5 kg each and link their little hands together to form dynamic, ephemeral structures.
Suppose the assemblers singing kumbaya shrink further; now each weighs only 300 g, and they are capable of acrobatically catapulting one another into the shape of the Walt Disney Concert Hall, or any other ten-thousand-tonne steel structure you like, in a few seconds.
(Wouldn't this waste a lot of energy? Probably not, though it depends on the efficiency of the machinery; the energy cost of lifting ten thousand tonnes an average of ten meters off the ground is about a gigajoule, 270 kWh; at 4¢/kWh that's US$11. In theory you can recoup that energy when you bring the structure back down, but lots of existing technology loses a factor of 10 or 100 to friction. Even at a factor of 100, though, the energy cost is unlikely to be significant compared to construction costs today.)
— ⁂ —
But tell me more about how programmers need to plan more to reduce the cost of construction mistakes?
That's why I really like PlantUML [1].
It generates UML diagrams from a simple text markup language.
Much quicker to iterate on, easy to put into a repo and share or collaborate.
Still not something you would use to design your whole code structure, but great for brainstorming or drafting once you internalized the language a bit.
Using visual diagrams is shutting out vision-impaired developers from ever participating in your process. Maybe you don't have any on the team now, but that could change.
PlantUML is screen-reader compatible, and it does a pretty good job of laying out the content of a diagram in a way that "reads right".
I don't think purely-visual diagrams are an appropriate part of modern development for this reason, not without a diligent effort to make an alt-text which conveys the same information. With PlantUML, you get the alt-text for free.
One might argue that UML could support the capture of such information, but what matters is that this rarely, if ever, was done. It is not the sort of information suited to being presented diagrammatically, or at least not by the sort of diagrams that made it into UML.
One might also argue that no other requirements specification method centered on these features has made it into mainstream software development. Some people here, for example, have argued that the code is a statement of requirements, and code also lacks these features. It does not follow, however, that therefore UML should have succeeded.
Ultimately, UML was an added layer offering insufficient benefits to justify its costs. Its benefits were insufficient because it was predicated on the false assumption that requirements can be adequately captured by a sufficient number of simple declarative statements about how things must be, and that the process of specifying requirements is primarily a matter of making such statements.
https://gist.github.com/ityonemo/9f3b8f86a04f2636ab308b1b1a3...
Eh, uml is a tool. Pretending to document fully or even to have uml as ground truth is a fool errand, of course, but since our daily job involves taming complexity, any system of knowledge partitioning that one can assume everyone else understand is a godsend
It was possible to get it to generate code, as I recall it basically gave you stubs of classes and methods and you would then go and code the implementation of each method.
It seemed like it could save you some amount of effort at basic boilerplate stuff but at the cost of putting the same or more effort into the UML.
UML was the swan song of the classic waterfall SDLC gang. Agile and TDD came along and nobody looked back.
There’s a ton of value in the idea of diagramming code and then generating sources. UML is a starting point but the journey is far from over.
The more appropriate idea is that you create documentation in the form of diagrams for free. Just like in TDD you get unit-tests for free.
Folks always talk about self-documenting code—and that’s great. But what about conveying a complex system to a new team of engineers? Diagrams are frankly priceless if done well.
Also, looking at something like Kubernetes where a declarative YAML file generates magic underneath is somewhat similar. A step beyond what we have would be nice diagramming capabilities over the YAML to auto generate the plumbing underneath.
Personally, I think future advances in development _will_ be done as higher level ideas—pictures worth a thousand lines of code—AI will do the rest.
I think a lot of it comes down to folks not bothering to invest in making good tools—or developers sticking to their current workflow.
That is why I relate it to Test-Driven Development because it does require a shift in process. But the end result, I think, could be very rewarding.
That is a nice benefit of good development frameworks: how easy is it to explore new ideas? And frankly that’s why there’s an uptick in higher level languages.
The problem is the diagrams are hard to create and hard to update and usually don't remain synchronized to the code. If there was a good way to create documents from the code (perhaps with some annotations required), it could just be a Make target and boom, free(ish) documentation.
Has been tried: https://github.com/CATechnologiesTest/yipee
And then for this to be held up as the example of how software engineering was going to be in the future is just icing on the cake.
I have many and sundry quibbles with various things I was taught in university ~20 years ago, but most of them I at least understand where they were coming from and some of them have simply been superceded, of course. But that software engineering course with Rational Rose has the distinction that, in hindsight, I don't think I agree with a single thing they taught.
I think only Clearcase had a bigger negative impact on productivity than Rose.
But the glimpse you got of it as an undergrad was UML trying to give it's last kick before dying. The whole quest for a formal definition and a standard for it doesn't make sense if you only want to use it to give an architectural level view.
Don't the UML and Agile and TDD 'gangs' overlap? Robert Martin has evangelised both.
I don't remember rapid iteration being a part of any UML-based methodology that I ever used. By the time the diagrams were complete enough to capture implementation details, they were too unwieldy. Did any UML tools support common refactorings, or would you have to manually change potentially dozens of affected diagrams?
===A====B==C=======>
A: (around 1997) We are hopeful that the methodology called UML will solve the software engineering problem.
B: We have tried that UML methodology and it doesn't solve the problem it said it would. We should try something else
C: (Feburary 2001) We have an ideology based on what we have found to solve the problem in practice, let's make a manifesto.
Of course, they have a book on sale to explain the new idea...
How much time was wasted and how many projects were damaged by the bad idea of UML and design up-front that they were pushing as hard as they could less than two decades ago? How many developers are being stressed by endless manic sprinting and micro-managing processes under the name of Agile?
Maybe they should stop? Or apply some actual science? Some of this in-group call themselves scientists but all they do is pontificate. I'm not really sure many of them spend much time actually programming.
This parody site is a fair characterization of what the current situation is: http://programming-motherfucker.com/
My favorite quote there is:
> We are tired of being told we're socialy awkward idiots who need to be manipulated to work... because none of the 10 managers on the project can do... Programming, Motherfucker.
Developers are better at self-organizing than people think. That is the real driving force in modern software. You can eliminate all the ceremonies of scrum and still have a functioning team. You can remove the scrum master and in some cases even the product manager and still have a functioning team.
Despite popular belief: developers CAN understand the product. In some cases developers can understand the product better than a product manager can. Also, developers can have a good approximation to what the customer wants, even without talking to the customer, by just looking at analytics data, log aggregations and bug reports.
The modern incarnation of agile gives too much power to product people and disempowers engineers, turning companies into tech debt mills. The original incarnation of agile empowered engineers and allowed them to collectively negotiate with the product manager.
Yoep, sure, maybe we even don't need clients. Just developers creating products for themselves. Or just coding for the sake of coding. I've seen that too mamy times. That's why we need product people.
Just like the largest corporations in existence became profitable and expansive before they hired MBAs.
Product managers and MBAs are the best examples of the Texas Sharpshooter cognitive fallacy. You shoot into a wall and then paint a target around it. Being successful at those roles is about painting targets around any successful initiative and claim it was your idea.
Powerpoint presentations are not reality, picking up the customer service phone, auditing the code, talking to internal and external users and keeping in touch with reality is.
"We hire smart people to tell us what to do". - Steve Jobs
The original agile manifesto emphasized collaboration with the customer. Scrum defined roles such as product manager and scrum master, and then the industry injected even more roles in between the customer and the developer...
Fast forward to 2021, we have "agile" developers that have never met a customer. So much for customer collaboration.
I even remember back in university you'd have to write your custom code _in_ the UML tools dialogs if you didn't want it to be overwritten next time you tried to generate code. Of course these were just simple text boxes. Horrible dev experience.
If you could wait the hours it took to do so. God that was the most resource hungry piece of software I've ever had the displeasure of using.
The Unified Modeling Language (UML) was the graphical language for Object-Oriented Analysis and Design (OOAD).
Classic waterfall was more of a top down, divide and conquer approach to software design and development.
Main point of UML is to tackle both diagramming/architecture AND forcing basic coding to reflect the diagrams. It forces code and documentation to both reflect the architectural truth.
This doesn’t have anything to do with agile methodologies, as any task can follow agile workflow.
> UML was going to be the "blueprints" of code, and software architects would develop UML diagrams similar to how building architects create blueprints for houses. But as it turned out, that was a false premise.
True. The blueprint is the code. The brick and mortar construction is done by compilers.
My preference these days is to use a text-based representation to generate diagrams with tools like Structurizr DSL, WebSequenceDiagrams, PlantUML and Graphviz. The source for the diagram(s) can be kept in the repo with the executable code and versioned.
Maybe in another decade we'll get some tools that can take the executable source code, along with all the deployment descriptors, the Kubernetes charts, Terraform configuration files, shell scripts, and so on and generate meaningful visualizations.
I don't know of any that can make it understandable, however. I think that would be a very difficult task, even for quite small, well-designed programs.
Code has a lot of relationships. In 2D it looks like a mess.
The promise "that with detailed enough diagrams, writing code would be trivial or even could be automatically generated" was made by "model-driven something". The idea behind that gets reinvented often. The latest one is called No-Code or Low-Code.
I guess it does work for Excel.
I use "pseudo-UML," as a "quick and dirty" diagrammer, but only when I want to do things like this: https://littlegreenviper.com/miscellany/swiftwater/the-curio...
I don't bother with the "official" definitions of UML. I kinda make it up as I go along.
Yes, prior to version 4.
> He ended up throwing in with Ivar Jacobsen
Jacobson had a proven method and toolset at that time called Objectory which was superior to Rose. Unfortunately they killed the tool. It seems to be an imperative of history that mediocrity prevails better.
Like many things, the big promise was a fad, but we learned some valuable things out of all of it, and some still survive.
I don't want to have to search "what does double arrow mean UML" in order to understand a proposal. I don't want an arrow to mean something that I couldn't learn somewhere else. I'd rather have a loose informal reference diagram alongside a couple paragraphs describing the system more formally. That way, the important information can be emphasized, the unnecessary information can be glossed over, and the diagram acts as a big-picture aide rather than some kind of formal semantic notation.
Everything is hard to read before you know how to read it.
After convincing the CIO that 'GREEK' is the silver bullet to their problems.
/s
If you're living in the Byzantine Empire, that is.
Besides, that's only half of my criticism. Greek is at least a full language where you have the flexibility to phrase things however you want and inject detail wherever you need. UML is a very rigid language which makes it hard to emphasize certain elements over others. A text has a reading order and a logical progression; UML is spaghetti.
If you're gonna write your docs in a different language, at least pick a good one.
Here's one that enabled some people to work a rich vein for a while.
https://en.wikipedia.org/wiki/Shlaer-Mellor_method
added:As an old person, there's no point in listening to me though. From where I sit, the main improvement over the last 40 years has been the widespread adoption of third party libraries. You'd be surprised at the things that had to be written from scratch. ...I just thought of another difference over time, the population of programming hobbyists who became professionals. It would kill me to write software for free.
The consultants got very rich with their cartoon drawings on the walls and nothing was produced for the taxpayers naturally.
A complete failure but because it's the federal government nobody was held accountable and the person in charge changed the success criteria enough to be able to cancel it and call it complete.
I'd say, as a direct corollary, the prevalence of API-driven services have been a welcome change.
I couldn’t have summarized it better than you just did. Thank you.
P.S., It's surprising that those who advocate that UML is better than code didn't understand the essential complexity would not go away simply because we switched a language, as essential complexity lies in precisely specifying a system. Neither did they understand that that a programming language offers more powerful constructs and tools to manage complexity compared with UML.
That is why I am fundamentally skeptical with the current push for Low Code or even No Code. Seems like people just don't really learn from the past.
That is, we let you take spreadsheets you already use and build more powerful collaborative tools on top of them, without code.
If you take the premise that a tool has a 'data' part, and an 'app' part, and that the data models the process, and the app more just controls how data is accessed, presented, the UX, etc, you might see why I'm so excited about this approach -- if you take the data from spreadsheets that are already being used to model a process in action, by definition you don't have to change your process at all.
The nice thing, though, is that shifting this structure around does not mean changing the process being modelled - it's more just a necessary part of making a more powerful tool to support it.
It's as you say, since the process is known, it's usually very clear exactly how the app should be, which under our model can inform how to shift the structure of the spreadsheet accordingly in pretty practical way. It's cool to see the same thing work in both directions!
In banks I know of some long-living spreadsheets that have been patched so much that it takes a real human weeks to months of work to disentangle the mess of macros and recalculations onto a streamlined script/process. Sometimes the resulting model diverges in quirky ways that are manually patched, I've seen diversions due to datetime issues (time zones, summer time, leap days, incorrect assumptions about dates, etc.) that were noted by side-effects of side-effects and the manual patching didn't help at all to debug the root cause.
I think that spreasheets are incredibly powerful, but the main reason for that power is that they are quite free-flowing and that invites the human creativity to solve problems with the limited set of tools and knowledge some users have, and some of those are in quite high technical positions using spreadsheets daily for years.
I believe you might have a killer product but I had so many headaches with spreadsheets that I wouldn't like to be working in that space.
Thing is, no one except him knew the DSL; everyone in the company relied on it, but they relied on him to write the DSL to compile their inputs into the output they wanted.
The rewrite included an actual database, proper data ingestion, and a nice clean frontend. The methods of aggregating data were reduced and standardized, as were the types of simulations and metrics that could be reported on; the flexibility was drastically reduced. However, the practical usage for everyone was drastically increased, because it moved from "we can't do anything different unless we get (expensive due to retire person's time)" to "we can do it ourselves.
I'm very jaded toward no/low code, in general, and that experience is partly the reason why. There isn't a sweet spot, that I've seen, that allows for non-technical people to have the control they want. And that was true even with spreadsheets.
So before you can start "shifting this structure around" you'll still have to go through a standard business analysis process to find out what you are going to shift it into. And if you're already doing that... Well, then most of your promise of automation is out the window already, so what's the use of having the actual implementation done in some weird newfangled "no-code" or "low-code" tool?
Understand the data and the application is simple and easy to understand. Start with a flashy GUI and your data is a mess.
I mean, couldn't many of the existing frameworks be described as low-code wrappers around more complex work flows and concepts?
Using frameworks, you are still using the language itself to command the frameworks. For example, if someone claims oneself as a React programmer, nobody would assume that someone didn't know Javascript.
So to efficiently use one framework, you should master both the language + framework. In other words, the complexity not only remains, but also accumulates.
But this is contradictory to low/no code's selling point, as they are targeting non-programmers.
Imagine how many tried flying before we "invented flight", and how many said "oh how they won't learn from the past".
Many alchemists tried to turn copper to gold as well. They might as well think that their predecessors are just unlucky by using the wrong implementation.
Which means that no code is either use case bounded or claiming something roughly on par with a break through. The first is common enough and where I imagine most low/no code offerings fall when the hype is stripped away. The hype seems to promise something on par with the second and I think that's where the dismissive attitude comes from.
An extreme example of this are logic and verification systems like prolog and TLA+.
There is a sweet spot of low code I haven't seen explored yet, which is a declarative system that is not Turing complete. That would be an interesting avenue to explore.
So I guess I still see declarative languages as being part of the tech stack and something tantamount to AI being needed to handle all the "do what I mean" that accompanies business process documentation.
It could be done directly if every BA had enough programming knowledge to put together schemas and run CLI tools to verify them.
That's quite a lot of programming knowledge. It makes some sense to decouple the business-oriented from the more technical roles - BA's trying their hand at coding is how you get mammoth Excel spreadsheets and other big-balls-of-mud.
As for formal methods, oh, where shall I even begin? The amount of time to turn something intuitive into correct predicate logic can be prohibitive to most of professionals. HN used to feature Eric Hehner's Practical Theory of Programming. I actually read through his book. I could well spend hours specifying a searching condition even though I could solve the search problem in a few minutes. And have you checked out the model checking patterns (http://people.cs.ksu.edu/~dwyer/spec-patterns.ORIGINAL)? I honestly don't know how a mere mortal like me could spend my best days figuring how to correctly specify something as simple as an event will eventually have between an event Q and an event P. Just for fun, the CTL specification is as follows:
``` G(Q -> !E[!R U (!P & !R & EX(P & E[!R U (!P & !R & EX(P & E[!R U (!P & !R & EX(P & !R & EF(R)))]))]))]) ```
As I said, formally specifying a system, no matter what tools one uses, is essential complexity.
If you went back in time to an age where people were working hard on changing lead into gold and your mission was to help them succeed as soon as possible, your best bet would probably be something like teaching them the decimal place value system, or how to express algebraic problems as geometric ones. But if you also told people that this knowledge was the key to solving the two problems they were working on, "how to make very pure versions of a substance", and "how to understand what makes specific types of matter different" you would reasonably have been regarded as deluded.
I don’t see how that follows. It’s just a truism that nobody figured out how to do it until someone finally did. The fact that the path wasn’t obvious at various points in the past seems irrelevant.
> But if you also told people that this knowledge was the key to solving the two problems they were working on, "how to make very pure versions of a substance", and "how to understand what makes specific types of matter different" you would reasonably have been regarded as deluded.
If they were listening to you at all, it’s not at all obvious why this part would sound deluded.
How is it any more exotic than any of the failed alchemies?
As far as I can see they were all quite abstract.
This one that happens to be correct, no less so.
The point is that 'just keep trying' would not have been a good strategy.
Yes, it’s possible that there are some concepts we have yet to think of.
See: https://numinous.productions/ttft/
The explanation of how hard it would be to come up with Arabic numerals if you didn’t already have them covers this.
However the point here is that we can learn from this, and we now know a lot more about how to do hard things.
‘It’s too hard and we should give up’ (the countervailing straw man) is even less supported by history than ‘keep trying’.
That definitely needs a citation. The Wikipedia page mentions no such motivation, and describes Alchemy as a proto-scientific endeavor aimed at understanding the natural world.
It just requires a particle accelerator and the amounts are so tiny that it’s ridiculously expensive. But hey, we can still do it!
I look at the code I'm writing (mostly C# thesedays) and I consider the _information-theoretic_ view of the program code I'm writing, and I see a major problem is that even syntactically terse languages (like C# compared to its stablemate VB.NET) still requires excessive, even redundant code in many places (e.g. prior to C# 9.0, defining an immutable class requires you to repeat names 3 times and types twice (constructor parameters, class properties, and assignment in the constructor body) which alone is a huge time-sink.
The most tedious work I do right now is adding "one more" scalar or complex data-member that has to travel from Point A in Method 1 to Point B in Method 2 - I wish I could ctrl+click in my IDE and say "magically write code that expresses the movement of this scalar piece of data from here to here" and that would save me so much time.
At least in modern languages like C# 9.0, Kotlin, and Swift (and C++ with heavy abuse of templates) a lot of the tedium can be eliminated - but not in the granddaddy of OOP languages: Java. Still to this day, I have absolutely no idea how people can write Java for line-of-business applications (its bread-and-butter!) and remain sane from having to manually manage data-flow, implementing Java Beans, and manually writing by-hand getter-and-setter methods...
Lombok, at the very least, eliminates “manually writing by-hand getter-and-setter methods” (https://projectlombok.org/).
Still... I feel strongly that Java eventually needs to adopt object-properties and reified-generics for it to stay relevant - otherwise it offers fewer and fewer advantages over competing languages - at least for greenfield projects at first, and eventually it’ll start being _uncool_ and fail to attract newer and younger devs to keep the ecosystem alive. Then we’ll end up with the next COBOL (well, more like the next Pascal/Delphi...)
I’d also add that while Java does suck in some fairly obvious ways, most languages suck and at least Java can actually run concurrent threads in parallel.
I probably would not choose Java with Lombok for a greenfield project today, were it up to me. But if I was forced to use Java, I would use Lombok. I was forced to use Java and I did use Lombok, and it didn’t really suck that bad.
The gap between post-8 Java and Kotlin is pretty small yeah. Though you have to write a lot of async plumbing yourself, and not having delegation is a real pain.
For whatever reason, it’s a lot easier for most organizations to sign off on using a specific library for an existing programming language, even one as transformative as Lombok, than to sign off on using a different programming language, even one as backwards-compatible as Kotlin. Often they are categorically different decisions in terms of management’s interest in micromanaging them: they might default-allow you to include libraries and default-disallow you to write code in a different language.
In this respect, Lombok is really handy for a very common form of unreasonable organization :)
It's been years since I did any of that, as Lombok and spring boot generate that code for you.
Immutable classes get a @Value and maybe @Builder annotation, muteable ones get @Setters etc.
Springs auto wiring for beans is sadly magical however, so much harder to figure out what went wrong if you have any issues...
Lombok requires that you use a supported build system and IDE and while all the currently relevant ones are supported that is no guarantee. Needs plugins and agents that support your various tools' versions including the JVM itself. I've been in that hell before with AspectJ and the aspectJ compiler vs eclipse plugin (version incompatibilities that made it impossible to work efficiently until they fixed it all up).
Disclaimer: last company we used Lombok. Current company we are switching certain things to Kotlin instead. data classes FTW for example. I do miss magic builders. Builders are awesome. Building the builder is tedious ;)
Aside from the fact Java only released non-preview support for records one month ago, they:
- Don't support inheritance
- Can't be mutable
- Don't have a copy method
match msg with
| IncreaseCounter cnt ->
{ model with Count = model.Count + cnt }
| DecreaseCounter cnt ->
{ model with Count = model.Count - cnt }
| ResetCounter ->
{ model with Count = 0 }
| ChangeRubric name ->
{ model with Rubric = name, Count = 0 }
For the rest, I agree that in 99% of the cases inheritance and mutability are not needed if you're using greenfield Kotlin libraries. But they are unfortunately often necessary in the Java world.
Mutable data classes are especially quite useful for reducing boilerplate when creating classes that implement the Fluent Builder pattern, which is unfortunately quite necessary if you don't have a copy method...
Copying objects is a well known need and there are countless libraries that try to help you with it. All with their own problems, notably runtime errors vs. compile time safety or pervasive use of reflection.
Spring on the other hand... autowired values everywhere, and at least for me (who doesn’t work with Spring day in and day out) it’s very difficult to understand where they come from.
We do use spring and I've used it for a very long time now. Nothing is magic and not understandable about wiring if you do it right. Unfortunately there are a lot of projects out there that use it in exactly the wrong way if you ask me and then I'd agree with you.
I used to be in a company where we used XML config and everything was wired explicitly. The XML part sucked but with SpringIDE (eclipse at the time) it was Ctrl-clickable to find what's what.
We use Java config with Spring at my current company and I can Ctrl-click my way through it all and find what's what. There's a small corner of 'package-scan'ed stuff that is evil but we are cleaning that up.
Because... We don't. IDEs and code generators have replaced a lot of the more stupid boilerplate. Not that there isn't a lot of stupid boilerplate in Java but it's been greatly reduced by tooling.
Still, I don't work with Java because I like it, I work with Java because it works and has a great ecosystem, the tooling around it make it bearable and without it I'd have definitely have jumped ship a long time ago.
I'm not only a Java developer, I've worked with Go, Python, Clojure, Ruby, JavaScript, Objective-C, PHP and down to ASP 3.0. Java is still the language that employed me the most and the longest, I have no love for it apart from the huge ecosystem (and the JVM gets some kudos) but it works well for larger codebases with fluid teams.
The issue now with Java is that it's such a big language and it's accumulated so much from many different paradigms that experience in "Java" doesn't always transfer across different companies or teams. Some teams hew closely to OO design and patterns, others use a lot of annotations and dependency injection, still others have gone fully functional since Java 8.
And then there are shops like one of my employers, where a large codebase and poor teamwork has resulted in a mishmash of all of the above, plus some sections that have no organizing principles at all.
I maintain that design-patterns are just well-established workarounds for limitations baked into the language - and we get used to them so easily that we rarely question why we’ve even built-up an entire mechanism for programming on-top of a programming language that we never improve the underlying language to render those design-patterns obsolete. (I guess the language vendors are in cahoots with Addison-Wesley...)
For example, we wouldn’t need the Visitor Pattern if a language supported dynamic double-dispatch. We wouldn’t need the adapter, facade, or decorator patterns if a language supported structural typing and/or interface forwarding. We wouldn’t even need to ever use inheritance as a concept if languages separated interface from implementation, and so on.
Better answer: the only real OOP system is Smalltalk.
Strict functional programmers have been saying that for years. They may be workarounds, but as patterns they have value in allowing one programmer to structure code in a way that is recognizable to another, even months later. You could say that a steering wheel, gas pedal, and brakes are workarounds for limitations baked into the automobile we wouldn't need if cars could drive themselves, but still value the fact that the steering wheel and the rest of the controls for a driver generally look and work the same across vehicles.
Patterns exist in functional programming as well, any map/reduce operation is a pattern, any monad is a pattern. It's a proven way to achieve a goal, it's easy to compartmentalise under a moniker and refer to the whole repeatable chunk with a name.
Unfortunately a lot of people only learn how to properly apply design patterns after doing it wrong and/or overdoing it (mea culpa here!). It's easy to spot the bad smells after you've been burnt 2-3 times.
(But I'm not trying to invalidate your claim that patterns exist in FP in general, only that specific case. Afaik, the Transducer abstraction isn't even widely-known nor used.)
Take the singleton pattern for example. It’s not perfect: it only works when constructors can be marked as private and/or when reflection can’t be used to invoke the constructor to create a runtime-legal second instance. A better long-term solution is to have the language itself natively support passing a reference to static-state, which completely eliminates the risk of a private ctor invocation - but that hasn’t happened.
OOP Design Patterns are like JavaScript polyfills: they enable things that should be part of the native platform. They’re fine to keep around for a few years when they’re new, but when you’re still using what is essentially an aftermarket add-on for 5+, 10+ or even 25+ years you need to ask if it’s the way things should be or not...
Who cares if you have to write setters and getters by clicking a button in IntelliJ, or have to explicit your types rather than ask every subsequent readers to use their brain as a type inference compiler.
Typing clear code isn't a problem Groovy should have solved by making it all implicit, at the cost of having non compiled production code. A code should never fail at runtime because you made a function name typo that it couldnt tell you about any other time for free.
So you also reject all dynamic and weakly typed languages? No JavaScript, Objective-C, PHP, Python, Ruby, Lisp, or Tcl? No type coercion at runtime?
> at the cost of having non compiled production code
Groovy can be compiled to the same bytecode as Java.
Here is something I made largely for my own use:
This is the TXR Lisp interactive listener of TXR 257.
Quit with :quit or Ctrl-D on an empty line. Ctrl-X ? for cheatsheet.
TXR is enteric coated to release over 24 hours of lasting relief.
1> (file-put-string "test.tl" "(foo (cons a))")
t
2> (compile-file "test.tl")
* test.tl:1: warning: cons: too few arguments: needs 2, given 1
* test.tl:1: warning: unbound variable a
* test.tl:1: warning: unbound function foo
* expr-2:1: variable a is not defined
Groovy is very quirky, and it's good at turning compile errors into runtime errors (@CompileStatic negates many of its advantages like multiple dispatch) and making IDE refactoring less effective. But the again, so is Spring. This got better when Java configuration was introduced... and then came Spring Boot, which is a super leaky abstraction, with default configuration that automatically backs off depending on arbitrary conditions (!). And yet people find it valuable, because it reduces boilerplate.
These days, I use Groovy mostly in testing (and Gradle), and it can really make tests more expressive.
You don’t like interpreted languages in production, fine. But rejecting candidates who think differently from you just creates a monoculture and reduces the chance that you learn anything new, beyond reinforcing your own convictions.
If you’re not going to write any tests, then obviously compile time is a crucial line of defense.
Most shops will be somewhere in the middle where compiler guarantees offer a real but marginal benefit, to be weighed against other tradeoffs.
The "tests for the tests" is code coverage.
And not only smaller languages, the tool set as well. Maven and Gradle for a start, and Gradle is its own Universe of little quirks and "what the fuck" moments. IDEs have a learning curve (but I learned vim and emacs before using any IDE so knew how steep learning curves work) and if you manage to use their features it can help immensely your productivity. Frameworks such as Spring have enough pull that it's easy to find interesting projects with it, I think that the direction of Spring Boot is pretty good for modern tech enterprises, at least for part of the stack.
Boring technology has its place, it's a hassle you have to learn a pretty big set of tools to be productive in Java but when you do you can actually accomplish a lot with multiple teams and a scale of hundreds to thousands of engineers.
You can also shoot yourself on the foot pretty easily, in massive scale, if the people taking decisions are architecture astronauts and not battle-hardened engineers who have suffered through incomprehensible code and piles over piles of mishmash of technologies and failed frameworks. Keeping the tech stack simple, boring and focused on a small set of tools has its benefits on scale.
I've been dealing with Java for about four years in an academic setting, not professional. When observing Java code in workplaces, the code bases have universally been bloated monstrosities composed mainly of anti-patterns - but that was hopefully down to the era these applications were written in (J2EE, Struts, etc).
My experience is that:
* Auto-generated code is still visual (and debugging) noise
* Annotations like Lombok's are great, but are "magic" abstractions, which I find to be problematic. They add cognitive load, because each specific library has its own assumptions about how you want to use your code, as opposed to built-in language constructs.
* Especially for Lombok, I can't help but think adding @Getter and @Setter to otherwise private fields is a poor workaround for a simple language deficiency: not having C#'s properties { get; set; }. I feel the same about libraries that try to circumvent runtime erasure of generic types.
* Compared to C#'s ASP.NET (core), I find fluent syntax configuration with sane defaults and "manual" DI configuration much more manageable and maintainable than auto-magic DI as in Spring, because at least it's explicit code.
* Java tooling (and if previous points weren't, this is definitely a subjective stance) just seems inferior and to set a low bar in terms of developer experience - maven or gradle compared to nuget, javac compared to dotnet CLI, executable packaging... As to other tooling, I suppose you're mainly referring to the IntelliJ suite?
I think C# (and by extension, Kotlin) had the right idea in seeking a balance through removing as much boilerplate as possible in base language constructs. Adding libraries is fine, but shouldn't be a workaround to evolving the language.
At the same time, a lot of that are artefacts of decisions made early in Java such as backwards compatibility.
The same for tooling, a lot of tools are results of its time, Ant, Maven and now Gradle.
Lombok has its pros and cons, I use it sometimes but had issues with Lombok and Java upgrades due to how Lombok writes out its bytecode.
I haven't touched javac in more than a decade so I don't really care about it, it's been abstracted away by my build tools (and I agree, the build tools are less-than-optimal).
Again, I agree with all the critics, at the same time just given how large the Java installation base is and by having to go through the Python 2 vs Python 3 migration path, debacles, etc., I still prefer to have all this cruft that is known, well discussed online, has documentation about its quirks rather than a moving target of language features over the last 20-25 years.
Java is too big due to all the evolution it went through, it could have taken different paths and modernised the language? Yes, at the expense of some core design decisions in the beginning. Do I agree with all these decisions? Nope, but who agrees to all design decisions made by their programming language designers?
Fluent-syntax, as it exists today, needs to die in a fire. It's horrible. It's abusing a core key computer-science concept (return values) and turning it into something that exists to only save a few keystrokes.
1. You have no way of knowing if the return-value is the same object as the subject or a new instance or something else.
2. It doesn't work with return-type covariance.
3. You can't use it with methods that return void.
4. You can't (easily) save an intermediate result to a separate variable.
5. You can't (easily) conditionally call some methods at runtime.
6. There is no transparency about to what extent a method mutates its subject or not. This is a huge problem with the `ConfigureX`/`UseY`/`AddZ` methods in .NET Core - I always have to whip-out ILSpy so I can see what's really going on inside the method.
Some libraries, like Linq and Roslyn's config use immutable builder objects - but others like ConfigureServices use mutable builders. Sometimes you'll find both types in the same method-call chain (e.g. Serilog and ImageProcessor).
What languages need is to bring back the "With" syntax that JavaScript and VB used to have - and better annotations or flow-analysis so that the compiler/editor/IDE can warn you if you're introducing unwanted mutations or unintentionally discarding an new immutable return value.
It does that, but it also makes your code read more like natural language. Perhaps I was careless in my wording, as I meant to point to manual, explicit configuration rather than fluent syntax per se.
As to your bullet points: I can see where you're coming from. I still think it's better than the invisible side effects and invisible method calls you get with annotations.
> What languages need is to bring back the "With" syntax that JavaScript and VB used to have
As far as I know, With... End With is a weird cross between "using" in C# and object initialisers. How does that help prevent mutations? One of the code examples (0) even explicitly mentions:
With theCustomer
.Name = "Coho Vineyard"
.URL = "http://www.cohovineyard.com/"
.City = "Redmond"
End With
var customer = new Customer {
Name = "Coho Vineyard",
URL = "http://www.cohovineyard.com/",
City = "Redmond"
};
var customer = Customer
.Name("Coho Vineyard")
.URL("http://www.cohovineyard.com/")
.City("Redmond")
.Build();
You don't write code for the machine, you write it for your team. It's fine if it's nice and comfortable, a bit repeated and fluffy, rather than terse and to the point.
Your code is only read by humans.
I don't care if you hand-coded all those buckets of accessors, or your IDE has generated them -- that's irrelevant to that they're still overwhelmingly useless noise. Which I need to read through, which I need to review in PR diffs, skim in "find symbol usage" output, class interface outlines, javadocs, etc etc -- all that 10 as often as during writing. Somehow I'm expected to learn to ignore meaningless code, while producing it is fine?..
Remember the point made in "green languages, brown languages" recent post here on HN? The insight for me there was the source of "rewrite it from scratch" urge which should be very familiar to engineers working in the field. It comes from incomprehensible code or weak code reading skills. Either way, boilerplate does nothing but harm.
So no, while I agree on your point that code exists principally to be read by humans (and as a nice secondary bonus, executed by machines) -- I disagree that boilerplate is "fine" whatever its incarnation. It's not, because it directly damages the primary purpose of code: its readability.
Of course your Java peers aren’t going to be happy about this, so in some ways a new language is needed to establish a context for this norm. But the limitation isn’t physical, not even in Java.
I disagree with this statement. Java just happened to become popular due to its C style syntax and various accidents of history.
Smalltalk is the true grand daddy of OOP languages and none of the issues you talk about apply there.
- Lombok library ( https://projectlombok.org/ ) generates all of the getters and setters, toString, equals, hashCode and other methods that classes typically should have (JetBrains IDEs allow you to generate them with a few clicks as well)
- MapStruct library ( https://mapstruct.org/ ) allows mapping between two types, between UserEntity and UserDto for allowing mostly similar objects or ones that are largely the same yet should be separate for domain purposes
- Spring Boot framework ( https://spring.io/projects/spring-boot ) allows getting rid of some of the XML that's so prevalent in enterprise Java, even regular Spring, and allows more configuration to be done within the code itself (as well as offers a variety of pluggable packages, such as a Tomcat starter to launch the app inside of an embedded Tomcat instance)
- JetBrains IDE ( https://www.jetbrains.com/ ) allows generating constructors, setters/getters, equals/hashCode, toString (well, there are covered by Lombok), tests, as well as allows for a variety of refactoring actions, such as extracting interfaces, extracting selected code into its own method and replacing duplicated bits, extracting variables and converting between lambdas and also implementing functional interfaces, as well as generating all of the methods that must be implemented for interfaces etc.
- Codota plugin ( https://www.codota.com/ ) offers some autocomplete improvements, to order them by how often other people used any of the available options, though personally there was a non-insignificant performance hit when using it
And then there's attempts like JHipster ( https://www.jhipster.tech/ ) which are more opinionated, but still interesting to look at. I think that model driven development and generative tooling is a bit underrated, though i also do believe that much of that could be done in other, less structured languages, like Python (though that may take more effort) and probably done better in more sophisticated languages, such as Rust.
All of this is possible today and not even that hard (though it's harder than meets the eye, there's a lot of issues that description glosses over that you have to deal with, especially in conventionally-imperative languages). The main problem you face is that the resulting code base is so far up the abstraction ladder that you need above-average programmers to even touch it. (I am assuming that this is merely a particular example of a class of such improvements you would like made.) This is essentially the same reason why Haskell isn't ever going to break out of its niche. You can easily create things like this with it, but you're not going to be hiring off the street to get people to work with it.
Or, to put it another way, a non-trivial reason if not the dominant reason we don't see code written to this level of abstraction is the cognitive limitations of the humans writing it.
I know HN doesn't really like this point sometimes, to which I'd ask anyone complaining if they've mentored someone a year or two out of college and fairly average. You can't build a software engineering industry out of the assumption that John Carmack is your minimum skill level.
My long-standing view is that Java's strict and verbose OOP syntax and semantics are an interface for IDEs. People who are hand-coding are practically guaranteed to be baffled by the verbosity, but they forget that Java development was the driver for IDE evolution (afaik), such that now we have ‘extract method’ and similar magic that understands code structure and semantics.
More specifically, OOP works, or should work, as an interface for IDEs that allows to (semi-)programmatically manipulate entities on a higher level, closer to the architecture or the problem domain.
Like you, I wondered if this manipulation can be harnessed and customized, preferably in a simpler way than giving in to the whole OOP/IDE/static-typing tangle and without writing AST-manipulating plugins for the IDE. In those musings I ended up with the feeling that Lisps might answer this very wish, with their macros and hopefully some kind of static transformations. Which are of course manipulating ASTs, but it seems to be done somewhat easier. Alas, predictably I've had no chance of doing any significant work in a Lisp, so far.
Nowhere near. There was a lot of OOP hype in the early 90s with Smalltalk and C++, so Java just went all-in (everything is in a class) on that trend of the times.
As such what we need is to have the right building blocks and abstraction layers which at the end will mean that something like no or low code will work. It will only work when all the tools that underpin it have been crystallised over the years.
This happens on every layer and is fundamentally why we see so much work repeated, but slightly different. Every language makes different trade offs, therefore all the libraries implement the same functionality but just a bit different this time.
Every once in a while something like UML (too complicated, e.g., due to the use of EJBs), Business Works (too slow), etc comes along which has promise and offers value at the time but just misses the boat to survive until the next generation of revised underlying tools.
If low code apps simply provide more flexibility and maintainability than a spreadsheet, they’re already winning.
https://www.microsoft.com/en-us/research/blog/lambda-the-ult...
You can even see this with stepped covid restrictions that rely on infection numbers crossing a certain threshold. Most engineers wlould imidiately see the real world consequences that arise from the lack of hysteresis.
Similar things happen with input sanitization, deciding on formats etc.
Some stuff just takes experience. The actual writing of the code is not the problem, the knowledge of what to do and what to avoid is.
It's too complex for them and the you pay Software engineers to use BEPL instead. Which is just a worse language to actually program in than the underlying system.
Or any other number of 'process engines' which give you a worse language to describe your actual process in and then you need to do stupidly convoluted things to do simple things. But hey, we didn't have to code!
In my experience these are usually too complex for non engineers to understand and incredibly frustrating for engineers to use.
I genuinely think they get a bad wrap because the really successful apps you never hear about, but the problematic ones need a real programmer to sort out.
Marketing Automation - Marketo, Klaviyo, Mailchimp as a few examples.
Airtable is another that has low-code automation built in
Budibase is built for internal tools so the apps are behind a log in / portal.
Once you can specify your procedures, requirements, and constraints in a way that is specific enough for a computer to read and act meaningfully on, the elements of your specification method become isomorphic to constructs in some programming language. So you've replaced typed-in keywords with clickable symbols or buttons or controls -- but you've in no wise reduced the headwork of programming or made the programming go away.
Just because certain information has an essential complexity doesn’t mean that different representations are equivalently complex. There’s an essential complexity to the layout of the London Underground, but it would be considerably worse if you had to represent it with plain text files instead of maps or diagrams.
I agree that UML was wrong-headed and simply ignored this complexity instead of addressing it seriously, but I wouldn’t be surprised if it turned out that some diagram-based programming language would be useful for something.
The lack of detail in the models means autogenerators have to have lots of configuration for each item in the diagram. People would brag that 95% of their code was autogen, and I would realize they had spent dozens of hours figuring out ways to use checkboxes and menu selections to generate the code they wanted. Instead of typing it. And all the hideous autogen vode was a nightmare to step through in a debugger. Large labview projects aren't any better really, but they are popular.
To be fair, that can’t be the only reason UML sucks, or even the main reason, because the same is true of Java, and while Java sucks, it’s a much better programming language than UML.
I think a lot of it really does come down to a denial of essential complexity. If you designed a visual programming language in such a way as to actually accept and handle essential complexity you’d be on a better track.
> The lack of detail in the models means autogenerators have to have lots of configuration for each item in the diagram. People would brag that 95% of their code was autogen, and I would realize they had spent dozens of hours figuring out ways to use checkboxes and menu selections to generate the code they wanted. Instead of typing it. And all the hideous autogen vode was a nightmare to step through in a debugger. Large labview projects aren't any better really, but they are popular.
I haven’t worked with these systems you’re discussing, but it sounds like people would be better off handwriting more of the code and only using the visual tools for the part that they’re actually better for. In much the same way that a Wikipedia article about elephants includes photographs of elephants instead of merely relying on long-winded textual descriptions of their appearance, while still having lots of text for the sorts of things text is good for representing.
I think maybe GUI interface builders or HyperCard might be another example of this hybrid approach. I think some incarnations of SmallTalk included similar ideas.
In general yes. I was only commenting on the assumption that UML can be of a general-purpose programming language, at least in the domain of business automation, or the idea that sufficient modeling can replace coding given the current technology.
I forgot the law's name but the said law states that "a machine of a certain complexity cannot build a machine more complex than itself". So, a car factory is more complex than a car itself. Similarly a code generator cannot produce something more complex than itself.
This is why you need to merge things of certain complexities to build something more complex.
Isn't this disproved by the evolution of reproductive organisms? That's not necessarily more complex of course, but it's pretty obvious that over a large enough time scale successive machines can become more complex.
Modeling all constraints and runtime behaviors in UML is cumbersome and hard to understand. UML could be used for showing larger building blocks or complex flows (e. g. with sequence diagrams), but it is a bad fit to model a complete program in it.
Regardless of the merits (or lack thereof) of the original push, I do want to see greater accountability and oversight of safety-critical systems and related, such as IoT systems - the idea of having a licensed/chartered engineer having to sign-off on a project (and so putting their personal professional reputation at stake) is something I support in the aftermath of things like Boeing's MCAS snafus - or the problems with Fujitsu's "Horizon" system - and so on.
I don't want occupational gatekeeping like we see with the AMA and the trope of licensed nail parlours, but we need to learn from how other engineering professions, like civil-engineering and aviation engineering, have all instituted a formal and legally-recognized sign-off process which I feel is sorely lacking in the entire software engineering industry.
There is value in diagrams - but that value is highest when the diagrams are derived directly from code. That is why I am making https://appland.com/docs - get the benefit of interactive code diagrams, generated automatically from executing code (not just static analysis, which is too weak to handle the dynamic behavior of modern frameworks).
That doesn't make the complexity go away, you have to do just as much work writing UML diagrams as you did writing code before, but now you're expressing your complexity in cumbersome visual designers rather than code.
If you're going to shift business logic/data from code to any other format you need to demonstrate that that other format is somehow better for representing that information, you can't just pretend that because it's not expressed in code any more you've gotten rid of it.
Because it might be different from the architecture you think you have and some bugs or opportunitues for improvement might be more easily spotted through this different lens.
IMO the bad rap UML gets is undeserved. The value of a detailed design in UML may be limited. But high level design elements like use case diagrams, sequence diagrams, activity diagrams - these are super useful.
Simpler "boxes and arrow diagrams" are fine but it's nice to have some consistency in the visual representation of these elements.
In Portugal I cannot sign a legally bound countract with Eng. SoAndSo withouth having been licensed to do so.
Naturally plenty of people without such duties never do the final exam, however the universities where they studied had to be certified by enginnering order anyway.
That may also be true for some areas, but you can def. sign a contract for software development with just a generic business license.
For example, I knew some consulting shops that had one poor soul that signed all contracts and hoped for the best.
Ironically, a lot of documentation systems now do the opposite: take your code and produce UML diagrams from it.
Software projects always used to go massively over budget, were delivered late, and usually didn't meet the customers requirements anyway.
It turns out that customers don't know what they want, or at least can't articulate it properly to business analysts.
By delivering early and often, we're not only releasing value to our customers early and often but we're getting feedback, allowing us and the customers to go on a journey of understanding their needs.
Also, it turns out that engineering teams know better how to develop a piece of software than architects.
We solve the complexity problems by breaking a project down into (as he says) "pizza team" size components and focus on defining the interfaces between those components, rather than go into the weeds of how information flows within the code. This leads to other complexities, of course, but they don't lead to the same sort of delivery problems that large, monolithic designs have.
All in all, a switch away from a design heavy approach has improved delivery, value to our customers, and enabled staff to be more productive.
I always try to start a new project assuming everything could change. Paradoxically, this approach tends to produce the same net result as assuming nothing will change. If you have no idea how requirements will evolve over time, there's no point guessing. Just write the code needed for the first batch of requirements, and nothing else.
It is orders of magnitude easier to add a layer of abstraction to a simple system when new requirements demand it vs. remove a layer of abstraction later when you finally realize you don't need it. The latter is often impossible.
I mentally call this "dumping all the Legos on the floor".
I think of abstracting as "sorting Legos" and think of the process of writing the minimal code as "dumping the Legos on the floor".
Once they are all on the floor, is easier to sort.
I feel like this is still the case under "Agile"
It means you can plan for and adjust early, rather than the week before a deadline.
Basically, we can't plan and estimate very well in tech, but it's easier to be accurate in our plans and estimates in smaller chunks than in larger.
Saying that, agile is about delivery rather than project management, and there always needs to be a larger roadmap to track features against - which is how we know if we're going to be late or not.
I think UML and its likes still have immense value between developers and teams to communicate complex processes in a way that is easy to understand at a glance and facilitate shared understanding.
I'd say this is suitable to give to an engineering team, along side a table with some endpoint detail, or even just the swagger. https://v2.developer.constantcontact.com/dotAsset/991381b5-0...
Whereas this is too much information and too hard to decipher at a glance: https://docs.microsoft.com/en-us/azure/active-directory/deve...
Diagram the higher level, leave the detail to other mechanisms.
The value of carefully-planned design is above the "pizza-team" level - that's the whole point of planning a system "in the large". The 'in the large' bit implies larger than pizza size.
"Getting feedback early and often" can only apply at the level of an individual component.
Plan at a higher level, execute at a lower.
A sequence diagram doesn't need to be ordered in a time sequence like UML, it can be good enough to just articulate and number the flow of information on a normal solution diagram.
A class diagram assumes we're using an OO language - we need to define schemas for data, but not classes. The engineering team knows how to structure their code, as an architect all we need to worry about are the boundaries.
That's not a surprise because of the prerequisite of being a good developer is to...well, write code.
I created an "Ask HN" topic to discuss what diagramming techniques development teams currently use:
Similar issue in UI design. Why draw up the mock when you could just make a static webpage?
With just a few Use Case diagrams, some class diagrams, and maybe some sequence diagrams, you could communicate what the final system should do and how people will interact with it.
The details of how to implement would be derived from the architecture used. I always found even a few basic diagrams with little detail (classes without fields) very useful and miss them now that people don't want to "waste time".
I think the proper comparison is then a suite of test code
Why would someone (especially someone non-technical) spend the time to learn and write what's essentially code to make a diagram when the alternative is drag and drop? That's not to say UML is without value, but to me it comes down to the difference between CLI and GUI tools: when the latter is broadly available to the masses, the former is only going to be used by power users who want the flexibility.
Another personal nit: I've never seen a "pretty" UML diagram. The value of aesthetics is obviously not critical, but if I'm looking to make a nice diagram to show my boss and the options are UML and Whimsical, I'm going with Whimsical every time.
GUI tools I find aren’t as good for iteration/living in source control/embedding in a wiki nicely. “As code” ecosystem is very immature - automatic live preview is frequently non-existent, resulting diagrams are ugly and hard to layout.
PlantUML is great but suffers from having a very difficult to customize layout, finicky styling, ugly default style, and a bit of a mess of a language that’s evolved organically.
I quite enjoy the C4 diagram stylings: https://github.com/plantuml-stdlib/C4-PlantUML
An advantage, depending on context, is that it brings the diagrams closer to the code that they're modeling, making it possible to version control them and include the diagram generation in documentation build automation.
The primary need for diagrams is drifting further from the use case you're describing.
Personally I always found that the less formalistic diagrams communicate much better since you can focus on providing the essential skeleton for your ideas rather than drowning in details that are only relevant in some contexts.
Also, UML does have some nice graphical notation like ——(o—— to denote interface and implementation (sockets and plugs).
this is a feature, not a bug.
The diagram isn't a substitute for the conversation. It's an aid for the conversation (and a way of remembering what was said afterwards).
The mistake was always trying to come up with a diagramming methodology that could communicate the entire design without the need for people to talk to each other.
Informal specs are just prose with maybe some diagrams. They are very helpful and not too labor-intensive to produce, so their usefulness is obvious, but they lack precision. Formal specs use some formalism to exactly define (often in some mathematics-inspired notation such as Z) the behavior of a program. Very useful if you have it, but labor intensive to produce, not too many people can read or write these comfortably, and keeping up with changing requirements is hard.
I think the selling point of pseudo-formal notation, like UML, was that it would be a "best of both worlds", where you get most of the benefit of formal specification, while the workload is more similar to informal specification.
Instead, my impression is that it's the worst of both worlds. The additional work isn't quite as high as for formal specification, but you get very little benefit for the additional work: the preciseness of your specification is still much closer to informal specs than to formal specs.
The vocabulary of UML offers a useful common ground (for example, distinguishing metamodels and class diagrams from object diagrams), but fancy UML features beyond the most basic diagrams would be not only time-consuming but off topic on a whiteboard, and too cumbersome and fundamentally informal for their intended uses of detailed design and model-driven code generation, with standardization providing strictly negative value.
I understand the appeal of saying you can ship the diagram rather than writing code based on it but it’s always felt like the kind of thing which leads to a demo cliff where the simple parts are appealing but anything non-trivial becomes unmanageable.
I just can’t wrap my head around this idea. If the act of coding isn’t the expensive part, then why should I have to spend so much effort coding and why can’t my effort be focused on the application complexity?
I agree that UML and past visual programming environments weren’t doing a good job of splitting these concepts, but I don’t buy that this means it’s impossible to split this.
I think a lot of business people also liked the idea of having one expensive architect giving diagrams to cheaper coders (probably in a different county), avoiding needing to give higher pay and social status than they needed to offer to be able to hire decent programmers. Something like UML is appealing if you want something you can look at to say it’s ready to hand over to be implemented and the numbers salespeople toss around for projected cost savings can make it appealing to pretend really hard that it’s that simple.
/sarcasm
13.5.11 A_signal_signalEvent [Association]
The value of UMLish things is just visually diagramming data and systems. Boxes with arrows and some data inside is typically enough to do the trick. Lucidchart is thriving despite many not actually writing explicit UML on it.
UML, specifically statecharts capture a lot of behaviour unambiguously, though it is hard to draw by hand (due to its hierarchical nesting possibility, so some kind collapse/expand system is required to draw them in a sane manner).
This is not to say that blueprint-style UML has no value, it's just comparatively rarer, since it requires much more time investment. However, the two do not address the same needs.
UML, as others have said, is both too precise about things that are still vague at sketch time and took vague about things I want to be precise about to be useful. And once I have a real system, the real complexity in the system always makes for either an insanely huge diagram with lines everywhere, or an imprecise one full of lies and omission.
Trying to program with UML is basically like trying to write a system of 10k lines by first writing them all down, and only then beginning to try to compile it. It's not going to produce good results, not just because of the endless little errors, but especially the big ones that your could have discovered much sooner if you were using something more real than UML. UML is superficially easier to work with than direct code, but in depth, I think inferior to it.
Some of the notation is sometimes useful, but to use it as intended is crazy.
Because UML is usually used when you don't yet know or decided many details.
If you put them on diagram they will often turn out to be wrong, or even worse - artificially restrict the implementator's freedom for no reason.
"Why do we require 10 clicks to upgrade the subscription plan?"
"Because that's how it was specified"
It definitely is, but are UML statecharts the right solution? Why not go the full nine yards and use a full-blown formal modelling environment, like TLA+? After all, using UML in a formal fashion would take more or less the same amount of effort as learning TLA+, which moreover:
* Is textual (making it easier to version-control and collaborate upon)
* Can be verified formally
It doesn't help that every UML diagram I've ever seen is ugly. There are always way too many jagged lines, and seemingly random attachment points. (Example: https://tallyfy.com/wp-content/uploads/2018/02/Class-Diagram...). In the little triangle, one line goes straight down, and one goes to the side. Is going to the side special? Or just a random artifact of the diagram? Without being an expert, it's hard to know.
With written-language descriptions, it's easier to be rigorous enough for all programmers.
Instead, I spend 70% of the time just trying to figure out a good diagram approach.
As I write this I can’t help wonder if perhaps it would be useful to return to UML after doing some exploration and before starting the real implemention. Still everyone on a project would need a refresh on UML, most of us forgot most of the details.
When you draw a diagram to communicate something about a system, being able to choose which things are important to you right now and which things aren’t is a feature of informal diagramming, not a bug.
I put the bare minimum of time into studying UML, and I'm glad I did.
> Explanation should do things that the other parts of the documentation do not. It’s not the place of an explanation to instruct the user in how to do something. Nor should it provide technical description. These functions of documentation are already taken care of in other sections.
Where UML goes wrong is that it tries to be a very detailed technical description. Usually, you just want a reference guide for that sort of thing. And reference docs are rarely maintained manually, at least not with any accuracy. I've yet to find a good system that can generate diagrams for technical reference that's usable.
It's hard to say what fits and what does not in a diagram, because it depends on the point you're trying to make. But I usually find that "explanations" are really tricky to get right. UML's a handy place to start thinking, but you're almost always going to cut out a lot of detail to make an explanation easy to understand.
They are very very useful for letting people quickly gain a shared understanding for what a system is supposed to do (at a high level). They are extremely beneficial IME.
If you are designing a system and need other people to understand key parts of how it all hangs together (e.g. during review or implementation or maintenance) , and you are not using sequence diagrams, I'd urge you to strongly consider doing so.
It seems weird that “No one is willing to waste time” updating diagrams, yet everybody who encounters a new large code base starts drawing diagrams.
It’s not clear to me whether making it easier to update diagrams or making it required (say by having the diagrams be part of the source code, without which the code won’t compile. There have been several attempts writing such systems, but none has become popular) will help there. Maybe, the act of drawing such diagrams (as opposed to looking at them) is essential for learning a code base.
[citation needed]. I got a new job fairly recently, we’ve got a massive codebase, and I never had the urge to draw any diagrams. (We’ve got zero diagrams as part of our docs as well.)
I draw a lot of diagrams when exploring code, but they are almost never uml, because usually I look at code searching for a particular information, and only draw what is relevant to that search with varying level of details.
If I was to draw everything (no matter the format) - it would become a huge mess with signal-to-noise ratio very close to 0, at that point I might as well just read the whole codebase.
This is another problem with UML in practice, that drawing diagrams is a skill, a bit similar to writing code in the sense that it is possible (and quite frequent) to have "spaghetti diagrams" with dozens of classes on one screen connected by long zigzag lines you need to carefully trace by finger.
The solution, as usual, is "divide and conquer", where you create a separate diagram for user management, another diagram for invoices, yet another for... whatever the application does. Okay, people do it partially, like they split 100 classes into two diagrams with 50 classes/tables each, but good design would be more like 10 diagrams with 10 classes/tables each.
Another problem is that the UML language cannot capture things specific for the project. For example, suppose that 80% of your classes have fields like "date_created", "date_modified" etc. How are you going to handle this? If you write those fields everywhere, you get lots of repetition. If you don't write them, you miss a potentially useful information.
With an informal diagram language, you could create a project-specific convention, for example a small clock icon in the corner would imply presence of "date_created" and "date_modified" fields -- and the icon itself would also be explained somewhere. A bit like graphical domain-specific language.
The UML spec actually has support for this. It defines a special kind of 'inheritance' between diagram elements and ways to represent it, including iconically.
This still comes to a head with Unreal Engine Blueprints.
"Starting here [main.cpp :: Start()], how do I end up here [Frobnificator.cpp :: FrobnifyQuux()]?" - should give me a sequence diagram like this one: https://s.plantuml.com/imgw/img-f05ecfe23bf545656a3a1f66b2a9.... And then I should be able to narrow it down, skip selected functions or classes.
I once spent over a day drawing such a diagram (much larger) for the core system of a large codebase I started working on. I did it by manually stepping through a codebase and making notes as I went, in PlantUML format. It ended up being tremendously helpful, as parsing a diagram like this is much faster than parsing textual representation. And a year later, when I had to revisit that part of the code again, despite being not entirely accurate, the diagram was still very helpful.
Same for other types of diagrams - class, state, component, activity, timing diagrams. The tools we have all have enough information (e.g. Clang definitely understands C++ codebases well enough that it should be able to spit out the aforementioned sequence diagram between two given points), but I'm not seeing them used this way.
To me, it seems that in their rush to criticize agile, the author failed to consider _why_ agile-like practices killed off UML.
A few random comments, on latest impressions of UML, while trying to get something done last week, but not a rigorous look UML...
I happened to skim parts of the UML spec (796-page PDF) last Thursday/Friday, having not seen UML in a while.
I appreciate all the goodness from various methodologists that was incorporated into UML. And, especially as a tools developer, I also appreciate the semi-formal metamodels, which have a few key uses, most of them for tools developers.
Unfortunately, the particular UML features I needed last Thu/Fri (for a cross-org high-level process&architecture model) didn't seem to be supported sufficiently well (or at all) by any of the first half-dozen UML tools I tried. (I tried open source, and then lightweight Web SaaS. People generally do that, maybe more SaaS first, and want to get started rapidly. I'm not going to casually install a huge closed CASE platform, without checking the SaaSes and open source.)
By Friday afternoon, finding all these tools hindered more than they helped, I said "fiddlesticks this barrier situation", and decided to just use our GSuite Draw. Although, on the surface, it appears to be pretty much 1980s shared-whiteboard simple drawing CSCW (with a little 1990 Visio diagramming innovations), I was able to express enough of what I needed without too much effort, and I was even able to reason from the diagram a little as I was manipulating it.
To make GSuite Draw viable for my immediate purpose of starting to work through a model, I did have to use a metamodel and notation that was easier to draw without special tool support, but it worked for this particular model.
I'd still use a specialized UML tool for the most familiar Rumbaugh-ian static object modeling. And, if the tool supported them well, I'd also use for Harel state modeling, maybe event traces, maybe Jacobson use case modeling, and some other UML ones (e.g., Activity Diagrams, especially with the object flows, not just flowchart control flows).
I wouldn't generalize much last week's experience, to adoption by developers in general, since I'm a fringe person who knows specific metamodel features that exist, which I want to select for a particular need -- rather than being a new person dropped in front of a particular kind of UML diagram, and told to start expressing my system in whatever terms it gives me.
I haven't done a rigorous survey of current method&tool practice and offerings, but I'm starting to form a suspicion that adoption and execution challenges for UML-ish things today are very similar to what they were 20 years ago. The markets certainly seem to have changed in some ways, but even some of those ways (e.g., more widespread framework reuse), were already being talked about for modeling 20 years ago.
- Sequence Diagram: great for understanding distributed workflows
- State Diagram: state machines are wonderful tools and having a standard for representing them is a win, IMHO
- Parametric Diagram[0] (SysML): feels like Class Diagrams for functional programming
[0] https://sysml.org/sysml-faq/what-is-parametric-diagram.html
Draw your workflow by writing down examples
Since then, OO has lost a lot of its luster, the languages most associated with it like Java and C++ are considered somewhat clunky and uncool. Functional programming took over as the “smart” paradigm to talk about, even if in practice most popular programming languages borrow a mix of imperative, OO, and functional features.
UML was also popular in a time when you could make a SQL database and just use that. The introduction of more database varieties complicates things.
Besides OO, UML was also strongly associated with “visual” programming done by non programmers. This paradigm is doomed to be reinvented and pushed as the next big thing every 3 years until eternity, which we currently see with whatever the latest no code trend is, but in the 2000s was associated with UML.
Finally, language independent data formats like JSON, Thrift, and protobufs got popular. Why make a UML diagram when I can just make the actual data structures then immediately have that as a binary format?
To the extent UML means “data modeling”, people still do that. But it became associate with a lot of cultural baggage, and most of that baggage was on the losing end of a lot of technology mindshare battles.
You sketch out simple diagrams of major modules and how they interact.
That gives an understanding of what goes where and how things interact at high level.
You dont detail each function/attribute/call/... you'd go insane and it would be useless / you'd lose your readers time. (If they want this level of detail they can check the code)
It's also useful when doing new big features where you need approval/feedback/advice. One simple class like diagram to show how you structured your code is generally useful for people you present it to to understand what you want. Some use cases like sequence diagrams are also useful. Then you detail out further in whatever is agreed in the company.
Sometimes its useful to describe flows for really complicated bugs with a sketch like sequence diagrams to make sure you undetstand and found actual root cause and to show that.
Now I just draw a few boxes with arrows and usually get the message across.
UML as code generator also made for really neat demos but in practice the diagrams for complex systems were harder to read than the code.
If I had one wish it would be nice if there was a standard for embedding and editing diagrams in different software like Word or Powerpoint or the web. It seems you always end up copying/pasting stuff while often losing the original after a while.
"IMO diagrams" are my favourite type of diagram
It's nice to ge an overview, but I don't bother to maintain these diagrams.
The "Three Amigo's" (Grady Booch, James Rumbaugh, and Ivar Jacobson) had different modelling methods and decided to "Unify". Most the the UML hype was about adoption and market penetration in order to get to an exit. Others were caught up in the hype and made some money too, such as Martin Fowler, who wrote UML distilled and went on to agile and Thoughtworks. Special mention to the now-unknown Alistair Cockburn who wrote a book and did a lot of consulting around the confusion of use cases.
In today's language, Rational Rose would be the "Uber of Enterprise Modelling" and UML and RUP would be it's moat. Or something - Hacker News would be very congratulatory of their achievements.
The question is less about why we don't use UML anymore (A: the three amigos got their exit), but why nothing has come along to replace it (A: it's not needed).
In the planning phases I just use Draw.io, but that always ends up out of date and irrelevant once the system actually exist.
If you model at the correct level of detail, you don't have pain keeping them in sync, one you start to model the implementation details you need to adding more complexity to your model to be able to sync the model :)
It seems to me that people emphasize the success of engineering disciplines outside of software engineering as a way to show the weakness of software engineering, but I think this way of looking at software engineering artifacts is misleading.
Optimization algorithms have some pretty dismal outcomes when you choose to analyze at a particular point in time, especially when you choose a failing artifact, because those failures are absolutely intentional and critical to the proper functioning of many types of optimization processes.
As an example generative discriminating processes, like GANs and like Software Creation + Chaos Engineering as popularized by Netflix, thrive on the creation of failure. Yet if you focus on the examples of failure you're missing the forest for the tree whose death is fertilizing the soil of the forest and resulting in a thriving ecosystem. Yes there was failure, but that failure wasn't an indication that the practice itself wasn't holistically valid. The failures were the means by which success was obtained. This falls directly out of the mathematics of learning.
The field envy of other engineering disciplines is misplaced. The limit of these optimization processes when expressed in code tends to be machine learning. These optimization processes result in learned creations of superior quality to what is currently produced and it seems highly likely that most fields that don't embrace this will find themselves out-competed by disruptive upstarts who aren't blind to the benefit of new technologies and workflows. Likely, some of these upstarts will be startup founders who frequent this site.
When you look at a time slice, failures look terrible. When you look at a longer period of time: failure is smarter than success. Risk aversion is self-destruction; die to live or you'll live to die.
I think most of people were doing UML-ish diagrams anyway because unless you really have a use case for it it is just wasting time to go full "UML".
Seems obvious at first sight, then you get 80% right in 20% of the time, and don't bother to put in the last 80% of time to get to 100% understanding.
When you will make perfect REST API there will be someone who will not understand it and will just try things and he might make a big mess.
The same if you will create beautiful, perfect, UML diagrams. If no one else is proficient using them and it is only you. There is no advantage of working this way.
using boxes and arrows isn't uml (full uml) and as you say, it's wasting time to go "full uml," which is why it died. diagramming will live on, even if inspired by uml.
I avoid even trying to use UML , because it just ends up in an argument about whether I’ve used it correctly, and is a distraction from whether the information displayed is correct.
Any UML diagram that accurately captured complex business requirements was no easier to understand than the pages of code, databases deployed, and a gazillion other things that are required to run any modern corporate.
UML - I know next to nothing about UML - but what I do know is the language was invented first and then people came around and tried to give semantics to the language. Well, in other words what that means is that the language was invented first and it really didn't mean anything. And then, later on, people came around to try to figure out what it meant. Well, that's not the way to design a specification language. The importance of a specification language is to specify something precisely, and therefore what you write - the specification you write - has to have a precise, rigorous meaning. - Leslie Lamport
UML: a language that was invented first and then people came around to try to get semantics. - Leslie Lamport
UML: fuzzy pictures of boxes and arrows. - Leslie Lamport
People use UML, things like UML, to model programs, but it's not clear how to translate them in to sequences of states, for concurrency. If you cannot translate them in to sequences of states, it means you don't understand them, and it may mean that there's nothing there. You know, there are lots of people selling snake-oil, drawing boxes and arrows that make you feel good, but ultimately have no real meaning. If something is really meaningful you should be able to express it in mathematics. - Leslie Lamport
UML was just another bad idea that wanted to reduce the complexity on business logic part but what it did in reality was:
- Add enormous complexity of UML on business logic
- Add enormous overengineering and complexity on "legoland" (code blocks that needed to behave by the UML spec)
- Add enormous complexity on a coding part (developers suddenly were no longer aware of the whole process and were not only doing stupid mistakes but were unable to optimize what could be optimized.
I was working on 200 million revenue project that was destroyed by architectural astronaut with "political connections" to upper management. At the end the whole dev. team was frustrated (those that brought the project to 200 million), top people were leaving and due to "generalization" of each "block" each feature took at least twice the time to deliver without all the overhead to actually get the conformation from UML "experts" what they actually need.
The further you go from the ground, harder it is to see the details. Once you float so high in space that Earth is only a ball, all problems / complexity / people / ... disappear. But it doesnt mean they are not there. You just cant see them. You are just playing with the ball.
The funny thing is that people just never learn, I bet there is a few thousands project running just now that want to do something similar as UML did.
As Alan Kay said, programming is a "pop culture", more interested in the latest fads. the fact that we have so many programming languages, many of them relatively recent, proves we don't really know what we're doing.
Through my tinkerings with Rasperry Pi's, I began to develop an interest in electronics. I recently decided that I'd actually study a book on GCSE Electronics (not sure what the US equivalent of that is called).
What it highlighted to me is that there's certain fundamental, timeless principles. Now, electronics is a relatively young discipline, but you can still go back decades. A lot of components we have now were actually available then, and ALL of the mathematical principles behind designing circuits remain the same.
Programming is the strangest invention of mankind. It seems to have resisted many attempts at codification of fundamental principles.
UML was borne to have a language to specify the design so that somebody else can implement it, or at very least that's how I have seen it used.
But this doesn't make sense in most cases. We have learned that the more efficient way to write the software is have one person both design and implement that design. And this means the UML has been relegated to serve as documentation only.
Which we know nobody likes to do and few do it.
The UML is still strong in organizations that write code to order or when comprehensive documentation is formal output of the process. This has been more popular in the past but these days companies that shape our development consciousness decided (and rightly so) that developing their products is core part of their business.
Modeling database structures, class diagrams, interactions between components is usually something, any senior developer can do on a napkin without all the hassle, certifications, $500+ per seat tools and unique terminology.
The trickiest things are designed much better, when you just open REPL and start playing with the design until you get it down. It's highly creative, speculative and flexible. So exactly the opposite of UML.
In programming, the most exciting parts are things you couldn't productively solve with UML.
And calling diagrams Masala is a huge misunderstanding why people mix contexts, views and representations. This is that creative, speculative and flexible part you exactly need.
So if UML is blueprints, it’s not that they failed. It’s that the creators misunderstood the actual fidelity of blueprints. They will never be perfect enough to replace implementation.
Sometimes I wish for more formal planning, and that real design could be done before code. But instead of building a design process, programmers immediately saw a way to automatically generate code, and in that they made UML useless.
I went to university just before UML had hit it "big". For some reason we learned three different ways to describe a class diagram graphically. Let's skip the part where we don't think that belongs to the university; it doesn't. But it does show how confusing things were, even to lecturers.
Now, if you were to bring me a class diagram with a completely made-up notation I'd immediately ask you to use UML notation next time.
It's not a big success, but a success nevertheless.
So good that Borland bought them up and shit canned it.
Today, its a convoluted mess that virtually no one tries to untangle in a professional setting.
Intelligent IDEs and the left-shift of Dev-Ops utilities have co-opted the CASE tools lunch. For sketching, Google's Draw.IO is superior by leaps and bounds to the heavyweight, commercial drawing products.
While that explains the UML-narcolepsy effect, the broader issue has always been the lack of systems and program design education.
It still is important to convey system and programming information beyond the cohort of programmers. I can tell you from experience that many accountable company business actors have NO IDEA what these systems actually look like in all the important ways.
What's missing is Computer-Aided Business Engineering tools.
UML was along the same lines as J2EE that rewarded bureaucracy and tedium.
UML is a relic of the worst parts of enterprise software back in the mid-naughts and I’m glad it’s completely dead.
It's a bit unwieldy, because of its OOP origins, but it helps me to visualize how code relates to other code and how software behaves at runtime.
What actually happened was programmers developed the code in Fortran, then ran a program that read the Fortran code and produced a flow chart on the printer.
After a while with this, the flow chart requirements were abandoned.
But there is a world of difference between "UML as a sketch" and using a diagram to constrain what actual code your co-workers actually write.
Sure – Fowlers’ UML Distilled is still handily placed on my bookshelf but even from when I first read it, I knew that I was never going to draw class diagrams from three perspectives (conceptual, specification ad implementation – leaving aside the GoF practice above). And in the 20+ years experience since UML became a standard I don’t think I ever did.
But turning it around, what diagrams do you draw when - You are in front of a whiteboard and are trying to communicate with half a dozen (maybe microservce based) teams that you need X to happen before Y but the daft business require you to pass a new bit of data through 3 of the systems to implement this. - You are in front of whiteboard with some of the newer members of your development team trying to work through what parts of their development can run in parallel and what parts must be serial (because the product owner is new and can’t get to that level of detail in words or drawings) - You want to explain to the business that one of "these" will own many of "those" unless (and if you are getting ambitious in your whiteboarding) the guard condition is that it is a pink moon or its aries ascendant
Me – I want one "diagramming language" to realise my witterings in. And that one "language" was always sketched UML for the last 20 years.
Sure – if I was a database designer implementing a problem with a relational database I might well use a ER diagram. But that is simply acknowledging diagrams are so much better than words for sharing ideas and the diagrams should be appropriate to the level of abstraction being dealt with.
As a previously enthusiastic Scala user, I'd say that the role for UML has been _very slightly_ decreased by the shift to functional from OO. But not much. The functional example of "map X to Y except when ..." is really about implementation detail and I think most people are happy not diagramming at that level now.
Good riddance.
As a new software developer in IBM, UML scared the hell out of me. It gave an aura of needless complexity to software problems that needed to be tackled by breaking them down into manageable chunks and apply time tested solution patterns.
And the whole Architect thing in IBM, oh my god. They were literally seen as demi-gods that everyone aspired to be. Really bad entry into software engineering for me.
(I have come out of IBM, so all is well)
Is it not uncommon these days to see UML sequence diagrams, for example...
I would describe the situation as:
- UML offers a lot of stuff, but only some of that became widely adopted.
- When stuff gets really ugly and complicated, UML can help by providing a high level view of what's going on in ways that are really hard to achieve just from memory.
Sometimes I use PlantUML to create diagrams to keep track of things. PlantUML is a format that is source control friendly, so I can check it in my docs folder.
If you're trying to break up a project into work for a large team, UML makes sense. Most people are clueless of how to do Test Driven Development right. I personally start with use case scenarios, then write console tests with dummy users named after my UML actors. By writing the console test with mock JSON data, you can quickly build high quality apps. The problem is when you have to update your UML, it becomes a time sink. Really we should have IDE and AI tools to reverse annotate the UML models. And CV tools to turn drawings on backs of napkins into UML.
I have not tried PlanetUML but it looks really cool, and it's my style. Comparative to StarUML, I would argue it's probably better for your creativity to type stuff out by hand but StarUML's CAD-like interface is very good. I personally run a startup that does pen-and-paper GitHub/Markdown integrations and I'm working towards converting my I am You Language (IMUL) to PlaneUML. It's competing with other products for attention though. I think that's the end argument about UML, it competes for time resources, I need help.
During the design phase, I'll usually write PlantUML code in IntelliJ and have the real-time preview fullscreen on another monitor. It's a nice setup.
We tend to go to either extreme, UML all the things (model driven design), massively over specify things before you write code. Then react by saying, this thing doesn't work when you try to do non sensible tings with it, its terrible, anyone who uses it doesn't get it.
The next gen of devs come along and thing its just for old folk who aren't down with the times.
Meanwhile, some people who never never fell into the trap of the extremes carry on to use it when useful and in a sensible way. Perhaps even try to show some newer devs the benefits, but have to now get past these preconceptions, even though the newer guys haven't any experience. These people are now often leading large engineering groups, and often want a basic overview of designs (not to the minuet detail), and really don't care about your classes, but please give me a sequence diagram so I can see how this microservice it actually going to fit in, and show me you have thought through the state transitions of the data.
The steps are called step 1, step 2 and step 3. The arrows between them must imply some. Kind of sequencing or dependency. If the person who drew the diagram didn’t mean to communicate that the execution sequence was step 1, then 2, then 3, they should have given the steps different names.
Simple dependency or data flow graphs like that are great for recognizing redundant dependencies, for example - like noticing ‘step 3 uses the results of step 1 and step 2, but step 2 depends on step 1 so we can just simplify this down to a sequential process - or we need to break the dependency of step 2 on step 1 so we can parallelize them’
This is notation to help you use pattern recognition and visualize structure to make better decisions, not to capture the final design. Diagrams are for helping with the ‘working out’ phase, not expressing the solution.
"Modeling software" really means writing a program in a high-level programming language.
The failure of UML was it's schizophrenia: Was it made for modeling the world, or for modeling programs?
If it had realized that is the case its creators would have asked: "How can we create a more high-level programming language than already existing ones?
But UML creators were happy to claim that they have a great "modeling language" because then there was no real need to make it executable. The fact that some applications could produce some Java-code from a UML diagram does not mean they could create full running programs from it.
I made the mistake of using UML. They argued about lines and shapes of the sequence diagrams for around 3 days. Then it was fonts. Then it was colors. They wanted images. They wanted all sorts of nonsense in the diagrams. But the actual content? Apparently not so important.
Three weeks passed without a single line of code and the requirements gathering still wasn't complete or even approaching a first draft. I aborted it before this project had a chance to go into actual development which was the next stage and a separate contract. I learnt many valuable lessons. Including the wise counsel of having a contract with exit clauses. Thank you to the lawyer who wrote it up at relatively minor cost. The same lawyer who apparently was a waste of time according to colleagues at the time. Colleagues I later abandoned when they made other stupid decisions. Always get contracts verified by legal representation. Sounds obvious. But apparently not.
UML wasn't actually the issue. I just lacked the crayons and experience to stop what would later come to be termed "bike-shedding". Because the diagrams etc were "human readable" it was deemed that anyone could have an opinion. So they did. Repeatedly. Ad nauseum.
Later projects went better when I limited the size of requirements gathering and who could make changes. Experience built up and my BS detector got a lot better.
But I kind of didn't mind UML as such. I actually prefer waterfall. Real waterfall is cyclic and resembles agile. But no one ever does it that way. They think it locks things in at each stage and the deliverables are like unchangeable stone tablets from on high. Ugh. So painful when done that way.
I disagree with the author's apparent take that all there is is either formal UML-type thought systems or a mess of design-less fluffy user stories. There is room for both.
But a thoughtful design represents and communicates deep thought, and formal design systems like UML, in my experience, do not help people communicate deep thoughts. The best design documents that I've read were very well-written prose, with occasional diagrams for illustration, or even code snippets, but not trying to convey too much in a formal manner which would've made the doc less readable not more.
That said, there have been plenty of times where I have used certain kinds of UML.
For example, sequence diagrams [1] are a great way of modelling certain processes between actors and objects within your system. I even used once a few months ago to help a client understand a complicated part of the system we had developed. I tend to think more junior CS graduates might end up pulling this kind of thing together using sticky notes in some web 2.0 board.
It's been dead for a while now. Just being brutally honest.
For states, I like plain old state diagrams.
Same goes for creating design: I prefer sketching code in notepad in a some kind of java/c++/python frankenstein over drawing uml.
I only find the the Doxygen generated inheritance hierarchies to be usefull.
Part of why OOP got so popular in software businesses is because it removes an impedance mismatch between the functions of business and the software it produces.
In this view, UML is a kind of intermediate bytecode between business planning and software planning.
Where it falls apart, IMO, is that UML is too granular for business functions, and it enforces a probably suboptimal OOP way of approaching technical problems.
Working on embedded software / hardware projects I've found SysML to be quite useful for systems design and documentation. Mostly BDD, IBD, Sequence, and State Machine diagrams. Parametric diagrams will probably come in handy at some point, as well.
SysML users tend to be in less vocal industries, especially those making expensive expensive hardware with lots of up-front design eg. defense, aero, medical, etc. I expect we'll keep using it until something better comes along.
1. Diagram-driven code didn't pan out as well as advocates hoped (and to the extent it was useful, UML wasn’t a great language for it; BPMN was less bad at this.)
2. Modeling and analysis became devalued, adversely impacting modeling languages
3. OMG also ended up as the owner of BPMN (which was also affected by the first two factors) which has enormous overlap in function with UML. So, with a reduced role for visual modeling languages you've got two competing standards in the area from the same organization, neither one of which is really adapted to current usage patterns.
We're using it via an executable process engine at my current company on a project that's not yet in production, so I'm still on the fence. I have no idea if anyone from the "business" side will ever look at these diagrams, and if it's just the developers looking at them, then why not look directly at the code with the support of a modern IDE?
The tools I used generated a system using storage-backed messaging between every step for reliability, and then I could plug in a UI or an integration where needed, and generating monitoring screens to illustrate where in the process things are, cycle times, etc etc.
If you use it like that, as a config language you can use to drive creation of other things, it can work well, and it's a pretty mature standard, so it can describe lots of possibilities.
BPMNs process-oriented focus is often viewed as both more general (tech neutral) and more suitable for high-level use than UMLs OO focus, and there are more low-level implementation diagrams in UML (e. g., Class diagrams) and more high-level context diagrams in BPMN (e.g., Conversation) but there is still significant overlap. BPMN Choreography diagrams serve exactly the role of UML sequence diagrams. UML Activity diagrams and BPMN Orchestration diagrams cover very similar space.
She found that programmers don't use it and architects barely use it.
My favorite quote: "There was a tendency for informants in large organizations who did not themselves use UML, or who used it selectively, to assume that colleagues in other roles were likely to use it more."
In case it's of interest, the things we were modeling were bilingual dictionaries, and morphology and phonology (linguistics), all of which had a ton of structure we needed to model.
I remember facing this dilemma early on in 2000s. When I was writing JSP (Java Server Pages), we did not have an easy way to ‘model’ a JSP as a software entity in UML. A JSP did serverside logic as well as Frontend. Then a forum suggested that we do what happens underneath that a JSP is compiled as a Servlet and model them as ‘JSP_Front’ and ‘JSP_Back’ as the accurate representation.
Architect
I like drawing dataflow when mapping integrations in IT projects out with UML flow diagrams, such as this[0]. But other than that I have never seen anyone use them. I could never find a use.
[0] https://www.researchgate.net/figure/UML-data-flow-diagram-be...
What UML did was to provide software engineers with a common language when illustrating designs on a whiteboard. I guess there wasn't any money in stopping there, so they had to write a spec and them have very expensive software being built to support this vision.
When I see a good UML diagram I know immediately what the bit of modelled code does. When I see a weird, cobbled together diagram of bits of code the creator thinks defines the state, I have gained nothing of value from viewing the diagram.
These few good parts can be used, or lifted from UML, without the rest of the UML baggage.
I did give up on WYSIWYG tools for this, though. PlantUML support in VSCode is pretty good.
So... yeah, sounds like it. Everyone I know that needs something UML could do just uses Draw.io these days.
I don't really agree with the premise that this is a big tragedy though. There's a danger of getting carried away with the analogy to traditional engineering but the cost of changing things in software is much lower, so exploratory work is much more viable.
The trouble with boxes-and-lines is that they work fine for small problems and collapse in a mess of overlapping nonsense for complex situations.
This is not a UML specificthing. Any visualisation that is boxes and lines that is not a strict acyclic single parent heirachy is doomed to failure for anything complex.
I've worked at two companies that started with database schema diagrams, but gave up on it. They got too complex to be useful, and people stopped looking at them.
It's the best method we have found so far to brief developers and for them to follow.
I have no idea what that article is trying to get at about multi-dimensional diagrams. I can make masala in UML, there's literally nothing stopping me.
This couldn't be further from the truth.
But I am the only developer in a team of >100 who does.
Now, the only UML that I use are Sequence Diagrams - a favorite notation for expressing time based things.
Here is one I tend to use with some regularity,
https://devblogs.microsoft.com/aspnet/grpc-performance-impro...
And then there is Visual Studio Ultimate as well.
We had whole semester long classes solely focused on designing systems with UML.
In my job I never did this ever again.
IBM buying Rational emphasized how corporate things had gotten and drove the point home that the Agile Manifesto signees were trying to make that basically was about eliminating inefficiencies and bad decision making from software development.
Extreme programming introduced the notion of a sprint measured in weeks and the notion of having working code at the end of each sprint. Later scrum, kanban and other agile methodologies copied at least those parts of the process.
Whichever your flavor of Agile is, two weeks does not leave a lot of room for maintaining artifacts that don't evolve along with code. Like UML diagrams. You draw a nice diagram, then you code for a week or so, and then your diagram is out of date. You could fix it by dedicating time to that. But you'd need to do so every two weeks. Or you just skip the part where you obsess about having diagrams and just move on straight to just worry about how to best run sprints.
Extreme Programming was extreme because it intentionally skipped both requirements specifications and design documents as things because they realized that requirements were a combination of wrong and out of date because of things you learned during the project. And consequently, the designs were wrong as well. You do a little bit of requirements and design each sprint. That's called a planning and estimation meeting. Requirements are called user stories now. And since there is only so much you can do to a software system in two weeks, you don't need a lot of UML documents to describe the changes you are going to make.
Along with Extreme Programming came tools like white boards, camera phones, and wikis. You use them to do a little white board session with typically some simple diagrams, you snap a photo of the whiteboard, and then put it on a wiki where no-one ever looks at it again. Good enough if you are doing two week sprints. The second you wipe the board, it fulfilled its purpose: sharing and communicating ideas and getting some consensus.
So, that's why UML died. It's no longer needed. Too expensive to create, more expensive to update, limited value once you have it, very limited shelf life once you stop maintaining it.
EDIT: here a few of my thoughts on the subject in case anyone is interested: https://www.quora.com/What-are-the-challenges-you-face-when-...
Part of the reason is to be able to use visual tools instead of defining everything using text.
I already explained why, people want to use visual tools.
SysML is also replacing the use of IDEF0 for the high-level requirements diagrams, finding IDEF0 software was getting too hard.
I'm not copying committee working documents from ISO livelink to somewhere else. If you want to read them then join the working group, Switzerland used to be a Participating Member back in the 90s.
Well, then it makes littles sense to refer to these minutes as evidence. From our discussion, I conclude that there is no reason to believe (absent evidence to the contrary) that "STEP (ISO 10303) is moving to use SysML to define the models for the collection of standards", neither as a replacement of nor as an equivalent alternative to EXPRESS. As a user of the standards, I do not care much which tools the working groups internally use to develop the standards.
ISO 10303-243 will not provide an EXPRESS schema at all, only JSON.
A new XML exchange format for models defined in SysML is being defined in ISO 10303-15.
ISO 10303-15 is apparently a technical specification on how to transform SysML XMI to XML Schema (XSD) format.
The main use case of ISO 10303-15 is to be able to validate XML exchange files in the new format.
I don't really see that there was a need for public relations, we are trying to maintain backwards compatibility with existing software and models.
Sounds like a statement from a state monopoly with a five-year plan.
Joking aside: You have just experienced a use case for this yourself. There is nothing at all on the web about what you claim. So I as a developer and user of the standards have no information whatsoever about what is bubbling up in the "black box ISO", if EXPRESS is really to be replaced by SysML (which I still do not believe). There is no mention of this in the presentations, strategies, and architectures I have access to.
Who is "we"? What's your role in ISO?
TC184/SC4/{WG11,WG12} - a mix of people who have been developing STEP since the start and some new blood.
I'm one of the older ones, I wrote ISO 10303-45 and maintain an EXPRESS compiler used in the document production process.
I see; this gives a new perspective to this discussion and increases my uneasiness; looks like the "holy wars of STEP" (NIST Special Publication 939) was going into a new round behind the scenes (or never stopped).
Does that mean we have to say goodbye to EXPRESS (i.e. it is optional as a description method)? Or is SysML just another method to specify Business object models (next to EXPRESS and UML)?
> an EXPRESS compiler used in the document production process
Do you mean the Eengine (written in Lisp)?
> Concerning "public relations":
e.g. the SysML v2 Submission Team (SST) did quite a good job in communicating their plans and the future direction of SysML; so even long before the standard is published I have a good grasp of what to expect, so also on the new text representation which will make MBSE much more efficient (like the advent of hardware description languages quickly made schematics obsolete for real world designs); this gives me enough time to prepare for the paradign shift (e.g. adapt my tools etc.). It is only to be suspected that STEP will still be based on the old SysML version with a different metamodel and no textual representation (i.e. the only "textual representation" is XMI or XSD).
Business Object Models are deprecated in ISO 10303-1e3 and replaced with Domain Models specified in SysML (v1), the ISO 10303-242 one will look very similar to the current BOM and will have alternative EXPRESS and XSD representations. The SysML Canonical XMI files that are the specification of the standard will be provided with it, a user can use the tools I linked to in order to convert this to something that can be loaded into a SysML editor.
Someone using ISO 10303 EXPRESS models now can carry on using them in the future, there isn't some change they are forced to adopt. The only real user visible difference will be a more complete mapping between a Business Object Model/Domain Model and the traditional EXPRESS Application Protocols.
I am maintaining Express Engine and adding new features, I'm not the original author though.
The problem they don't speak about that UML is not universal, it has serious flaws.
# Complexity as a Modeling Language
It can only be understood by those extensively trained in UML. Really, show someone a UML diagram and they won't understand them. What are those arrows supposed to mean? The boxes. etc. About a dozen different diagram types don't help either.
In fact, I have seen so many faulty diagrams, activity diagrams that contain error and mistakes because the semantics were not properly understood that just confirms how complex UML is. Furthermore, I was in UML corporate trainings and the instructor made mistakes about UML activity diagram semantics, etc. It's that bad. From that perspective, thinking that a business person may be able to understand is wishful thinking
# Object-Oriented Paradigm and the 'Encoding' Problem
UML at its core assumes object-orientation. That means that class-diagrams replace Entity-Relationship diagrams. Class diagrams may work as an 'encoding' of ER diagrams, but its fairly complex. This is a pattern that repeats for a couple of applications of UML. It is possible to model a lot in UML, also by extending UML with its possibilities to extend it, but the results really look like a strange encoding and its hard to read these diagrams.
Overall UML has replaced a Zoo of diagram types that were more or less established and the results are often not pretty. I made a deep dive once into diagrams of the 80ies and 70ies and overall a lot felt refreshing.
# Model-based Engineering and Tool Vendor Takeover
I haven't been involved in UML prior to version 2, but it overall feels like UML is a vehicle by vendors of UML tooling to sell their products and as such, UML has adapted the idea of model-based engineering.
When the naive assumption of a software engineer about UML is, that a couple of Visio/draw.io/Dia diagrams will do, one learns over time that its hard to maintain these models, and the fix for it is to use a modelling tool such as Enterprise Architect or Rhapsody that contains a whole Tree of UML entities from which you derive your diagrams as viewpoints. Its like falling through a rabbit whole. If you manage to avoid this rabbit whole it just means you probably are only using a small subset of UML.
I think this lead to UML becoming increasingly complex and the language standard should probably have been limited in a way that it remains useful without the tooling.
# Lack of Block Diagrams and Data-Flow diagrams
If you look at ad-hoc (non-UML) diagrams in open-source documentation and corporate ppt slide decks, or look at diagrams your colleagues draw on a whiteboard, what one really quite often sees is diagrams that show data flow, as in: "Frontend in the Browser requests data from the backend service, backend service retrieves data from the SQL database and the object-storage system". These simple relationships are remarkably hard to nicely communicate in UML. Hence, if you intuitively start to describe a Software system, UML will not make it easy.
# Whats the alternative?
I am personally a huge fan of FMC (http://fmc-modeling.org) but am the first to admit that it is a little obscure, but it offers everything I consistently need.
* block diagrams for data-flow and system interactions, structure * Petri nets for behaviour * E/R diagrams for data structures.
Surprisingly, the diagrams seem to be fairly approachable for engineers and business people alike. A lot of the micro design decisions for the FMC diagrams have been done right. In block diagrams, arrows point in the direction of data flow, everyone can understand that. In E/R diagrams, the 1:N relations also have arrows pointing to the `1`, that's somewhat easy to grasp. Petri nets are equivalent to UML's activity diagrams, but don't omit the drawing of 'places'. With places being drawn, people have at least the chance to grasp the semantics and firing rules (that are also present in UML's activity diagrams but people just don't make that connection).
FMC is a bit more your whiteboard diagrams, slightly formalised.
I never liked the arrow-direction in uml
How do you do that?
I actually saw a kid a few years ago with a huge UML book, a student at the local uni. Being self-taught I had no idea what it was so I had to look it up. I can't even come close to working with those actual engineers, I just mess around in Bash and automate stuff you can learn for free using open source.
> I can't even come close to working with those actual engineers,
Then how do you know they still use UML if you've never been around them?
A very American perspective!
https://en.wikipedia.org/wiki/Canadian_Council_of_Profession...
But people don't call us engineers just because we know a bit of linux. It's mainly because we solve problems, just as well as you do.
I have a friend who works at Saab engineering and knows UML. He studied for 7 years at uni, I dropped out of 10th grade.
There's a huge difference and yet people call me an engineer in certain contexts.