23 ms·
UML's promise was that that with detailed enough diagrams, writing code would be trivial or even could be automatically generated (there are UML tools that can
by jdlyga 6y ago
UML's promise was that that with detailed enough diagrams, writing code would be trivial or even could be automatically generated (there are UML tools that can generate code). It was developed during a time when there was a push to make Software Engineering a licensed profession. 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. The real blueprints for software ended up being the code itself. And the legacy of UML lives on in simpler boxes and arrow diagrams.
- ch_123 6y agoCompletely agreed. As for why the code is the blue print - good code design requires the ability to switch between high level details (how do I structure these high-level components of the system) and super low level details (e.g. the application of a particular algorithm to a certain problem, or the various hacks and workarounds one often has to write when dealing with certain third party systems). The lower level details simply cannot be extrapolated from a high level structure.
- lazide 6y agoTo extend the construction analogy a bit - typical architectural drawings aren’t buildable as is. They often miss key details (member composition is rarely even mentioned, same with even member sizing!). Stamped civil engineering plans will often miss anything which is outside of the core structural elements being certified (so good luck figuring out the size of the beam you’re supposed to put somewhere if it isn’t a core load bearing element). Huge portions of construction are based off decades of (inconsistent) experience, in the field improvisation, cargo culting, and gut feel. The smaller/less big Corp the job, the more true this is.
- agumonkey 6y agoThe thing is I found quite paradoxical (to stay polite) that you'd spend time drafting something that is not precise, not data to help you but just a document in a tool. 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.
- radicalbyte 6y agoModel driven isn't dead though, it has transformed. It's all about text models now. The only thing you really see is people using clicky-clicky tools to make databases.
- AnimalMuppet 6y agoThere can be a stage between "I have kind of an idea of what this is supposed to be" and "I'm ready to code this", where you think carefully about what this thing is actually supposed to be, and how it's supposed to behave and interact. It's not amiss to think for a bit before creating the code. 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?
- robertlagrant 6y agoIt certainly isn't the optimal way. Imagine the UML for a metaclass that creates classes, or for composition/trait based object definitions. The good UML diagrams are sequence and maybe use case.
- reificator 6y ago> > 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. 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.
- dnautics 6y agothis is what I do... I have a UML document that describes the database schema and instead of autogenerating it, I run a compile-time check to verify that the UML is in sync with the schema.
- Buttons840 6y agoHad UML succeeded at that goal, I think it's funny that hackers would have probably built a text based language to generate the UML diagrams.
- alexott 6y agoPlantUML & other tools exists for quite a long time
- posixplz 6y agoPlantUML is an excellent tool for creating visual representations of system behaviors. Because diagrams are generated from plaintext, they’re easy to maintain and version control. I use it often when designing new features and systems. You don’t need to pay attention to UML semantics to create valuable diagrams.
- theshrike79 6y agoPlantUML also integrates pretty well with different wikis. The textual representation is saved in the wiki and the image is generated on-demand.
- alexott 6y ago100% - that’s my primary usage of it. It’s easy to encode complex diagram and change it easily.
- zorked 6y agoHackers wouldn't touch UML with a 4000000000000 kilometer pole.
- Y_Y 6y agoIt would be difficult to do really anything with such a pole.
- 6y ago
- throwawayboise 6y agoI used one of those tools at one point, Rational Rose. 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.
- bakatubas 6y agoI dunno I disagree—the fact is a lot of people just dive into coding and don’t spend much time with design. 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.
- pjbk 6y agoGranted, but you can do the same and much more with different methods, and avoid fighting the frustrating, unreliable and time-consuming UML tools altogether.
- bakatubas 6y agoI can’t argue _for_ any particular tool—just that the concept is a really good concept. 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.
- segmondy 6y agoThe challenge is that when you're making enough detailed design ahead, you are back to waterfall so it's not really compatible with the agile methods of today.
- bakatubas 6y agoHonestly, I think complex architectures are best demonstrated as diagrams—and those can be developed in an agile fashion. Stable, well-thought-out architectures can’t be slapped together without nice diagrams. There’s a ton of folks who just “start coding” to get a feature going, but when someone else takes over the project, how are they to learn the code? Diagrams are always the best way for me—and there’s limits on what doxygen says, depending on how bad the implementation is. 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.
- mavelikara 6y agoMartin Fowler discusses this here: https://martinfowler.com/bliki/UmlMode.html https://martinfowler.com/bliki/UmlMode.html > 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.
- midnitewarrior 6y agoPerhaps the better choice was to have automated tools to turn source code into understandable business diagrams to allow business analysts to partner with software engineers, instead of the other way around.
- michaelmrose 6y agoWhat useful information is this going to convey to the business person and how is it going to be better than a conversation with you.
- ajcp 6y agoBusiness continuity and inheritability of business applications by both the business and developer.
- cratermoon 6y agoThere's value in visual representations of complex things. See for example Edward Tufte. People probably just think of him as visualizing data, but his book Visual Explanations goes into many other areas. 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.
- 6y ago
- qznc 6y agoUML is a language or notation. It isn't dead and I consider it still useful because a standardized notation means you don't have to explain your notation again and again. Or worse you forget to explain the notation and people are confused what that arrow or box actually means. 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.
- worldsayshi 6y agoThe problem isn't uml itself but the fact that the uml definition is separate from the code. Is still see that there can be done use of visualizing parts of the code using uml.
- astrange 6y agoA related one that people keep reinventing is “dataflow programming”, where programs would get more expressive if we didn’t call and return stuff but instead data just moved around those arrows on a graph. That’s like code generation but you actually execute the graph. I guess it does work for Excel.
- ChrisMarshallNY 6y agoI remember "Booch Blobs." The original system diagrammer was Grady Booch, and he used these little "clouds." I think Rational Ro$e used them. He ended up throwing in with Ivar Jacobsen, and they came up with UML (which Jacobsen started). More boring, but also more practical. 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-curious-case-of-the-protocol-default/#what 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.
- Rochus 6y ago> I think Rational Ro$e used them 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.
- lazide 6y agoThe funny thing (having lived through that time) was that while it was very trendy to pretend that construction was not a giant disaster most of the time from a planning, delay, cost overruns, etc. perspective - it was pretty clearly not the case even then if we’d looked even a little! Like many things, the big promise was a fad, but we learned some valuable things out of all of it, and some still survive.
- bccdee 6y agoI've always really disliked UML because it tries to strictly encode a whole lot of information into diagrams, which is way too rigid and opaque for me. My eyes just glaze over when I see UML. 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.
- michaelcampbell 6y agoThat's not a fault of UML. I can't read Greek but that doesn't make it unreadable. Everything is hard to read before you know how to read it.
- water8 6y agoYea but, why do we have to speak in Greek in the first place?
- canada_dry 6y agoSo consulting companies can make bank teaching you how. After convincing the CIO that 'GREEK' is the silver bullet to their problems. /s
- kragen 6y agoBecause that's the language the laws are written in. If you don't speak Greek, you don't know what the law is, so you'll break it. That's a bad idea. If you're living in the Byzantine Empire, that is.
- BlueTemplar 5y agoSame can be said about English with regards to programming. Most people don't have English as a native language.
- kingsuper20 6y agoI think it's main promise was to sell training and materials to large companies. Nice work if you can get it. Here's one that enabled some people to work a rich vein for a while. https://en.wikipedia.org/wiki/Shlaer-Mellor_method 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.
- JPKab 6y agoThe Wikipedia article you posted is very relevant to me because I watched a division of the Air Force waste tens of millions of dollars trying to implement that approach for their collection of IT systems. 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.
- mpyne 6y agoWatched (and still watching) the same thing in the Navy. :(
- macintux 6y ago> From where I sit, the main improvement over the last 40 years has been the widespread adoption of third party libraries. I'd say, as a direct corollary, the prevalence of API-driven services have been a welcome change.
- ryanmarsh 6y agoI invested much of my early career in model driven architecture with UML. Including diagramming tools, dev rel, XMI transforms, code generation, etc. I couldn’t have summarized it better than you just did. Thank you.
- andrewfromx 6y agowow, that is perfectly worded. In 2001 I spent a great deal of time making these UML diagrams for my boss. I didn't understand what this had to do with writing code. I hated it. Tried to argue it was pointless, lets just skip these and start writing code... and there was crickets
- hintymad 6y agoIBM used to push the adoption of their business process software for exactly the same reason. They imagined that "business process experts" use UML to construct the entire business process, and then the software (based on WebSphere Application Developer, an Eclipse-based IDE) will generate all the execution code, including deployment scripts. The irony is that the UML itself becomes more complex than code, and dozens of layers of exception trace were simply incomprehensible to engineers, let alone to "business process experts". To add insult to injury, IBM mandated generating tons of EJBs. Even thinking of that induces migraine. 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.
- karmasimida 6y agoWell said. 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.
- bitwize 6y agoLow-code/no-code is simply the CASE tools of the late 80s, or the UML->production system fully automated pipeline of the late 90s/early 2000s, given new life and a shiny coat of paint. The same problems apply and the same people keep buying the same damn snake oil. 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.
- emodendroket 6y agoEverybody promises their no-code solution is going to adopt to the way your enterprise already works, but the truth is you kind of have to go the other way around if you don't want misery.
- dehrmann 6y agoPart of the reason for this is that until you get to larger system components, changing the code is relatively cheap, so there's less need for a formal design.
- gentleman11 6y agoI use it exclusively during refactoring to try and spot coupling, or to figure out somebody else’s code with a sequence diagram. It’s handy for that. It would be weird to use it for up-front design but I guess you could
- DaiPlusPlus 6y ago> It was developed during a time when there was a push to make Software Engineering a licensed profession 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.
- UncleOxidant 6y agoI never understood the appeal of UML. Hardware design had been done almost entirely by schematics, but then in the mid 90s HDLs (Hardware Description Languages) and logic synthesis offered increased productivity for hardware designers. Now other than very highlevel block diagrams hardware design is almost completely textual. UML seemed like schematics for software and a step backward.
- Rochus 6y agoThat's the right perspective to look at it. It wasn't just increased productivity which brought us to HDLs, but it was the sheer impossibility of understanding or keeping track of the ever larger and more complex designs with schematics. With todays software systems we have exactly the same problem (but computer scientists apparently prefer to retry and reinvent things than to study anything old). UML (and with version 2 also SysML) finally had an equivalent textual representation, but it was much too late.
- kgilpin 6y agoIndeed. The problem is not with the diagrams, so much, as with the requirement for people to draw them. The code is the source of truth and the only true representation of the program. 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 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).
- p1necone 6y agoIt seems fundamentally obvious to me that this line of thinking is bogus. If you move enough of the complexity to UML diagrams of course the code will be simpler - because all the complexity is now in the UML diagrams. 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.
- scotty79 6y agoI'm kind of missing something opposite. A tool that can draw a diagram out of the code, that by dropping some details but preserving important stuff like what objects travel through which fuctions, can give you better understanding of what architecture in your program/system do you actually have. 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.
- has2k1 6y agoSee this [1] article by Martin Fowler. UML promised and pushed for more control over how much of the program it could sketch/model. 1. https://martinfowler.com/bliki/UmlMode.html https://martinfowler.com/bliki/UmlMode.html
- scotty79 6y agoI'm missing "UML as a satelite map of the wilderness"
- wyldfire 6y ago> But as it turned out, that was a false premise. The real blueprints for software ended up being the code itself. And the legacy of UML lives on in simpler boxes and arrow diagrams. 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.
- nunez 6y agoHonestly, UML would have been awesome for backend architecture. Most backend architecture I see are logos next to boxes connected by arrows, which is fine for high-level but extremely difficult to automate
- pjmlp 6y agoSoftware Engineering is a licensed profession in several countries. 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.
- ORioN63 6y agoI don't think I've have ever met a software engineer in Portugal that is on the "Ordem de Engenheiros". It's far more common, because indeed they're legally bound, with civil engineers, material engineers and such. That may also be true for some areas, but you can def. sign a contract for software development with just a generic business license.
- pjmlp 6y agoThere are certainly creative ways to sign the contract in order to avoid that requirement, after all we belong to the European nations that tend to be creative when it is time to comply with the law. For example, I knew some consulting shops that had one poor soul that signed all contracts and hoped for the best.
- professoretc 6y ago> writing code would be trivial or even could be automatically generated (there are UML tools that can generate code) Ironically, a lot of documentation systems now do the opposite: take your code and produce UML diagrams from it.