[HN Gopher] Has UML died without anyone noticing?
___________________________________________________________________
Has UML died without anyone noticing?
Author : azhenley
Score : 363 points
Date : 2021-04-25 17:31 UTC (5 hours ago)
(HTM) web link (garba.org)
(TXT) w3m dump (garba.org)
| emodendroket wrote:
| I've been at it 8 years and never actually seen anyone use it, so
| I think of it as a relic of an era before my time.
|
| 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.
| radiator wrote:
| Interesting point of view. The article is not really only about
| UML, but about formal specifications in general, and how Agile's
| rise affected them.
| vegetablepotpie wrote:
| Yes and UML is not dead, it was just never the tool that most
| people needed.
| cartoonfoxes wrote:
| I've never encountered UML in the wild, but could say a few good
| words for SysML, which is built on top of UML.
|
| 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.
| disposekinetics wrote:
| I've never seen UML used at a company in any form, despite being
| required to take a class that taught UML.
| msla wrote:
| It's about as dead as flowcharts and Warnier/Orr diagrams are.
|
| https://en.wikipedia.org/wiki/Warnier/Orr_diagram
| throwaway4good wrote:
| Yes. It was killed by post-it notes and coloured sharpies.
| jdlyga wrote:
| 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.
| DaiPlusPlus wrote:
| > 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.
| segmondy wrote:
| The 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 wrote:
| Honestly, 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 wrote:
| Martin Fowler discusses this here:
| 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 wrote:
| Perhaps 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 wrote:
| What 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 wrote:
| Business continuity and inheritability of business
| applications by both the business and developer.
| cratermoon wrote:
| There'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 a meaningful visualizations.
| qznc wrote:
| UML 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 wrote:
| The 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.
| dehrmann wrote:
| Part 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.
| ch_123 wrote:
| Completely 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 wrote:
| To 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.
| ryanmarsh wrote:
| I 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.
| UncleOxidant wrote:
| I 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.
| gentleman11 wrote:
| I 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
| agumonkey wrote:
| The 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 wrote:
| Model 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 wrote:
| There 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?
| reificator wrote:
| > > _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.
| xh-dude wrote:
| Agreed ... the thing that bothers me about UML is that it
| has displaced better, smaller-bore tooling in a significant
| way. The idea of thinking-before-coding work is of course
| completely necessary.
| lazide wrote:
| That assumes that before you have a thing in your hand (a
| working program with expected input, and output), you can
| exactly describe how that thing should act, what it should
| look like, what the input and output should be (and not be)
| and have that be successful - and structured correctly
| internally the first time.
|
| 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.
| randoramax wrote:
| It's weird to read this because building's architects and
| designers do exactly that: they have to make tremendous
| efforts to design complex systems (think an airport or a
| hospital) before they lay down a single brick. Somehow
| this idealization and planning step is impossible for
| software developers.
| gpsx wrote:
| A ways back, the president at a multi-discipline
| engineering consulting firm I worked in made an
| interesting point. If you give ten EEs a hardware task,
| they will come back with something that looks similar. If
| you give ten software engineers a software task, they
| will come back with ten completely different things. I
| think this is because in software there are so many
| possible ways to do something, and so much richness, that
| writing software is a very different from making
| hardware, or architecting a building, to go along with
| the parent comment.
| nosianu wrote:
| There are quite a few responses, but I still want to
| point out a main difference more clearly:
|
| 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.
| andi999 wrote:
| I start to think that this step is actually the code. An
| architect has to specify things because the drawing is
| not the building, while for programming the 'drawing'
| actually is already the program.
| vanviegen wrote:
| The interesting question is how they organize these
| tremendous design efforts before laying the first brick.
| In software, there just is no construction phase after
| the design phase.
| lazide wrote:
| Nod, we don't have to deal with the pesky issues of
| moving actual physical objects to be in specific contact
| in certain ways with other physical objects. Once we
| figure out a design that compiles (in commercial
| construction, that would be a plan that passes
| validation/sign off), we're 'done' except for the pesky
| bug fixing, iteration, follow up, etc.
|
| 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).
| emodendroket wrote:
| I suspect it probably is possible, if you're willing to
| spend enough time. However, it's also true that the cost
| of a building's architect changing his mind in medias res
| is far higher than the software developer's. It is not
| necessarily the case that the best way to approach one
| discipline is also the best way to approach the other,
| just because we happen to have decided both should be
| called "engineering."
| 8note wrote:
| The constraints are different. If compilation took 3-5
| years to complete, software would look more like civil
| engineering.
|
| The goal of 3d printing and the like is to make
| mechanical engineering more like software so you can get
| a tight iteration loop
| throwawayboise wrote:
| Good point. If you remember the days when compiling your
| program meant taking a deck of punch cards to the data
| center, handing them off to an operator, and then waiting
| a few hours for the result, you spent a lot more time
| planning your code and running it through your mental
| line-level debugger than you do today.
| Ankintol wrote:
| Those engineers have the good fortune to be working in a
| fairly constrained space. New materials and building
| techniques become viable slowly over time.
|
| 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.
| lazide wrote:
| Also, the construction industry is a huge mess, and
| anyone telling you that things don't go over budget, get
| torn out because someone messed up a unit conversion
| somewhere, burn down during construction because someone
| didn't follow some basic rules, or turn out to be nearly
| uninhabitable once complete because of something that
| should have been obvious at the beginning - is just
| ignorant. These happen on a not infrequent basis.
|
| 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.
| galangalalgol wrote:
| Buildings are naturally described by drawings, logic is
| naturally deacribed by notation. We wouldn't ask a civil
| engineer to design a building using prose, and so we
| should not ask a computer engineer to describe logic
| using boxes and arrows.
| nobodyandproud wrote:
| Decades of coding here.
|
| 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.
| lazide wrote:
| Hah! The funny part is, you think they don't mess this up
| all the time, but they do! We all have experiences with
| buildings that are impossible to navigate, have weird
| maintenance issues (toilets always backing up, A/C a
| nightmare, rooms too small, rooms too big, not enough
| useful space, etc). Buildings get redrawn constantly
| during construction, and they rarely match the plans.
| Cost overruns are endemic, as are scheduling issues.
|
| 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.
| armagon wrote:
| I remember watching a documentary on architecture, and
| the speaker, who offering a different approach, said that
| for much of architecture, the never-look-back mantra was
| the unspoken rule of the day.
|
| 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.]
| PLenz wrote:
| At the beginning of my career I worked in AEC on the
| planning side. It was well understood that whatever the
| Architects had designed would be entirely redone by
| engineers afterwards and then by on-site engineers and
| then by tradespeople after that in the implementation. No
| one really understands what's going on in a reasonably-
| sized building.
| lazide wrote:
| Addressing the real needs of people is hard, and gets in
| the way of being famous and changing the world - a
| mindset I've seen more than a few times in designers. All
| of them pretty senior? So I guess it was working for
| them?
| HotHotLava wrote:
| It's not that software engineers are not capable of doing
| the same when required (e.g. in the firmware for NASAs
| mars rovers, etc.) but that usually software engineers
| don't do that because _there is a better alternative_.
|
| If architects could build a house multiple times a day
| while slightly rearranging the layout every time they'd
| do that in a heartbeat.
| water8 wrote:
| Bingo! Architects don't get to debug their building with
| the press of a button.
| username90 wrote:
| They do however make computer models and simulations to
| understand the problem. Programmers do that as well by
| coding parts of the problem, running it to simulate usage
| and see how it works and adjusting accordingly. No bricks
| needs to be laid for software engineers to work either.
| mannykannot wrote:
| I agree completely with your first two paragraphs, but UML,
| in my opinion, failed to support that approach. Its primary
| failure is that it neither captured nor communicated the
| rationale behind the requirements, the answers to "why
| this?", "why this, instead of that?" and "is this right? is
| it sufficient?" Answering these sorts of question is
| central to the production of requirements and also to
| understanding them, but with UML these questions and their
| answers are treated like scaffolding, taken away from the
| result before its delivery.
|
| 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.
| robertlagrant wrote:
| It 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.
| the_duke wrote:
| > You'd want to design in some other medium
|
| 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.
|
| [1] https://plantuml.com/
| japanuspus wrote:
| Completely agree with this sentiment: Don't include every
| detail in your UML, but use it instead to straighten out
| your high-level ideas. PlanUML is also my go-to for this.
| samatman wrote:
| I want to add an important affordance of PlantUML:
| accessibility.
|
| 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.
| galangalalgol wrote:
| Why would you ever _not_ want to iterate your design? Doing
| is the fastest way of learning. The details can drive a
| design, so that if you don 't remove all ambiguity, you
| will create an architecture that won't actually work. The
| problem people who just jump in face, is that they do not
| abandon their bad prototype and begin again, instead
| clinging to faulty architecture which leaves them in the
| same boat as someone who made an architecture unaware of
| the details.
| dnautics wrote:
| this 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.
| red0point wrote:
| Nice! What tools do you use to achieve this?
| dnautics wrote:
| it's about 125 lines in elixir:
|
| https://gist.github.com/ityonemo/9f3b8f86a04f2636ab308b1b1a
| 3...
| bccdee wrote:
| I'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 wrote:
| That'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 wrote:
| Yea but, why do we have to speak in Greek in the first
| place?
| hintymad wrote:
| IBM 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 wrote:
| Well 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.
| dgudkov wrote:
| Comparing UML and No-code is apples to oranges. UML is
| about generic abstraction without actual implementation.
| No-code is about domain-specific implementation done using
| simplified high-level visual constructs instead of general-
| purpose programming languages. In other words, No-code is
| programming (just not text-based), while UML is modelling.
| plnii wrote:
| Some strange comments in here about Low Code, as if they
| weren't already successful. There are easily hundreds of
| apps successfully making use of Low Code to solve problems
| for people. Some Marketing Automation tools have had them
| for 10+ Years. Integration tools are also often Low Code.
| gilbetron wrote:
| Have any examples? (Genuine question, not an attack!)
| I've mostly ignored the Low/No Code stuff for a long
| time.
| emodendroket wrote:
| Everybody 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.
| dzhiurgis wrote:
| Salesforce kinda nailing it (and I say that as Salesforce
| code crafter, not their no code user).
| davnicwil wrote:
| I work at Stacker (YC S20) [0] and the approach we're
| taking to deliver on this promise is to start with the
| data.
|
| 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.
|
| [0] https://stackerhq.com
| throwawayboise wrote:
| About 30 years ago one of my managers used to say "get
| the data model right and the application writes itself"
| and I have found that to be mostly true. What I have also
| often found is that people who create spreadsheets in
| business don't understand data modeling and even if the
| spreadsheet solves some business problem it's often very
| brittle and hard to change and adapt or generalize.
| davnicwil wrote:
| The spreadsheet structure point is an interesting
| challenge - I think often a spreadsheet ends up as the
| _de facto_ model of a process, but often with, as you
| say, some redundancy, excessive flattening, and other
| structural issues that can make it more diffcult to build
| an app around.
|
| 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!
| piva00 wrote:
| From my experience working with some business-side using
| spreadsheets: yes, usually spreadsheets end as the de
| facto model of a process but not necessarily an efficient
| model or an easily replicable one.
|
| 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.
| mathattack wrote:
| This!
|
| Understand the data and the application is simple and
| easy to understand. Start with a flashy GUI and your data
| is a mess.
| emodendroket wrote:
| So basically MS Access as a service?
| DaiPlusPlus wrote:
| > Low Code or even No Code
|
| 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...
| piva00 wrote:
| > 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...
|
| 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.
| cratermoon wrote:
| Ward Cunningham once noted that because a programmer can
| input incomplete, or minimal, code, then push a few
| buttons to autogenerate the rest, that there's a smaller
| language inside Java. Since he made that remark a number
| of other JVM languages have sprung up that try to be less
| verbose. One of them is Groovy, which uses type inference
| and other semantics to reduce duplication (or
| "stuttering" as Go calls it").
|
| 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.
| 411111111111111 wrote:
| I use java8 at my dayjob.
|
| 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...
| peterpost2 wrote:
| this resonates so much to me
| philwelch wrote:
| > 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/).
| mikeappell wrote:
| I think this is only partially true. There are aspects of
| coding which can be abstracted away, either because they're
| essentially boilerplate or because a simpler description of
| the solution is sufficient. Ideally if a more complex
| description is required, one can drill down into the
| simplified low-code description and add sufficient
| complexity to solve the problem.
|
| I mean, couldn't many of the existing frameworks be
| described as low-code wrappers around more complex work
| flows and concepts?
| karmasimida wrote:
| > 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.
| [deleted]
| spockz wrote:
| I strongly believe that every tool, every invention, can
| only innovate/be innovative in one area.
|
| 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.
| atoav wrote:
| I think a certain set of problems requires the thinking of
| someone who knows how complex systems work and where the
| pitfalls are.
|
| 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.
| pushrax wrote:
| A spreadsheet is a low code app. Less flexible than a
| general purpose programming language, but still extremely
| valuable.
|
| If low code apps simply provide more flexibility and
| maintainability than a spreadsheet, they're already
| winning.
| ideamotor wrote:
| No Code is mostly a code word for outsourcing. You use
| their app to get it started, realize it won't meet your
| requirements, and then pay them to work on it forever.
| Unless it's just a marketing Website.
| capableweb wrote:
| Some people see past tries at something as proof that
| something will never work. Others see past tries at someone
| having the right idea, but wrong implementation.
|
| Imagine how many tried flying before we "invented flight",
| and how many said "oh how they won't learn from the past".
| mmcdermott wrote:
| I think that's a fair point. The way I see it, going from
| requirements (even visual ones) to working system would
| require strong AI, as any sufficiently powerful visual
| environment would wind up being Turing complete.
|
| 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.
| hctaw wrote:
| Functional and declarative programming are mostly
| specifying requirements directly. You don't need a AI to
| do it, in fact that would be the wrong tool (AI is good
| for fuzzy problems and inference - not following a spec).
|
| 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.
| mmcdermott wrote:
| Business requirements still have a measure of ambiguity
| and "do what I mean" to them. They are more formal than
| natural language, sure, but fall far short of the
| formalism of a declarative programming language. This is
| a big part of the business partnership underlying most
| Agile methodologies. If the formal spec could be handed
| off, then it would be and Waterfall would work better in
| enterprise settings. Instead, the team is constantly
| requiring feedback on the requirements.
|
| 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.
| hctaw wrote:
| I think honestly the problem is a lack of tech literacy.
| I've seen spec sheets that are glorified database and
| json schemas in a spreadsheet, put together by BAs and
| translated by hand.
|
| It could be done directly if every BA had enough
| programming knowledge to put together schemas and run CLI
| tools to verify them.
| zozbot234 wrote:
| > 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.
| rurp wrote:
| True, but on the flip side imagine how many people tried
| transmuting lead into gold, thinking the previous
| attempts simply used the wrong approach.
| zepto wrote:
| They were right. The previous attempts did in fact use
| the wrong approach, and _people have now successfully
| turned lead into gold_. The only problem is that it's too
| expensive to be worth doing.
| sharpneli wrote:
| To be honest we actually figured even this one out.
|
| It just requires a particle accelerator and the amounts
| are so tiny that it's ridiculously expensive. But hey, we
| can still do it!
| ScalaFan wrote:
| It would have been sad if we had given up on AI/ML ideas
| due to the failure of AI back in the 80s/early 90s. See:
| https://en.wikipedia.org/wiki/Fifth_generation_computer
| karmasimida wrote:
| Either outcome is possible.
|
| 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.
| int_19h wrote:
| And they were correct: we do know how to turn copper to
| gold now; it's just prohibitively expensive.
| malwarebytess wrote:
| They're trying to commodify writing code. It would bring
| down the cost of programmers significantly. They won't
| succeed, I think. Instead AI will probably beat them to it.
| temporallobe wrote:
| Low Code/No Code solutions don't work because the people
| involved in implementing solutions are rarely engineers
| themselves. Most (good) engineers have learned through
| training and/or experience, well, engineering things, like
| edge cases, error handling, user experience, efficiency,
| testing, maintainability, automated testing, and a plethora
| of other subtle and obvious aspects of system design. I
| know this quite well because I've worked with these so-
| called low-code and no-code platforms and every one of them
| I have seen end up having to be taken over by experienced
| engineers who have been brought in to fix (or in some cases
| completely rebuild) a poorly-designed system. These
| platforms typically suffer the "last mile" problem as well,
| requiring someone to write actual code.
| philwelch wrote:
| Could the problem simply be that UML was poorly designed for
| the job?
|
| 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.
| galangalalgol wrote:
| Simulink, labview, and gnu radio are all fairly well
| adopted though they all have their problems. They are all
| notably not oop, at least not idiomatically. In fact, as
| most blocks are stateless other than their configuration,
| you might say the paradigm is closest to functional. UML,
| with the exception of flow charts was very OOP centric. In
| a world where I still come across people who use OO as a
| synonym for "good" I can see why they created it that way,
| but a tool that shapes your design space can be limiting.
|
| 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.
| philwelch wrote:
| > UML, with the exception of flow charts was very OOP
| centric. In a world where I still come across people who
| use OO as a synonym for "good" I can see why they created
| it that way, but a tool that shapes your design space can
| be limiting.
|
| 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.
| galangalalgol wrote:
| The hybrid approach failed miserably for us, but that
| could be the tool, it forced a lot of things through the
| GUI with no option to bypass. I noted elsewhere that
| diagrams are natural for civil engineering and notation
| is natural for logic and other branches of math. That is
| because of the "essential complexity". I think it is
| possible there will be a great general purpose
| programming diagram tool some day, but I've never seen
| one that wasn't either very domain specific, or downright
| terrible.
| hintymad wrote:
| > 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.
|
| 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.
| mathattack wrote:
| It did justify an army of billable systems analysts as they
| tried to deskill their engineers.
| Buttons840 wrote:
| Had 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.
| hjek wrote:
| Those tools exists already. I used PlantUML[0] at my
| programming course. UML is nonsense, of course, but it was
| part of the curriculum, and it was more tolerable doing UML
| in Vim than in a graphical point-and-click editor.
|
| [0]: https://plantuml.com/
| avereveard wrote:
| > UML is nonsense
|
| 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
| [deleted]
| [deleted]
| alexott wrote:
| PlantUML & other tools exists for quite a long time
| posixplz wrote:
| PlantUML 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 wrote:
| PlantUML also integrates pretty well with different
| wikis. The textual representation is saved in the wiki
| and the image is generated on-demand.
| alexott wrote:
| 100% - that's my primary usage of it. It's easy to encode
| complex diagram and change it easily.
| kevin_thibedeau wrote:
| It's inevitable. Most digital FPGA and ASIC development is
| done with HDLs despite the availability of schematic entry
| systems. 2D representations of behavior do not scale, are
| hostile to collaboration, and suffer from vendor lockin.
| zorked wrote:
| Hackers wouldn't touch UML with a 4000000000000 kilometer
| pole.
| TeMPOraL wrote:
| Sure they would. As a widely recognizable set of boxes and
| arrow shapes, it's useful for the kind of doodling that you
| might want to show someone else later :).
| oddmiral wrote:
| Challenge accepted.
| PurpleFoxy wrote:
| When I was in uni recently I was learning UML and wondered
| why all the FOSS tools for UML sucked. I quickly worked out
| it's because no foss programmer actually uses or cares
| about UML
| Y_Y wrote:
| It would be difficult to do really anything with such a
| pole.
| oddmiral wrote:
| UML is the virtual thing, so it will be a virtual pole,
| of course.
| andrewfromx wrote:
| wow, 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
| ChrisMarshallNY wrote:
| I 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-curio...
|
| I don't bother with the "official" definitions of UML. I kinda
| make it up as I go along.
| lazide wrote:
| The 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.
| kingsuper20 wrote:
| I 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
|
| 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 wrote:
| The 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 wrote:
| Watched (and still watching) the same thing in the Navy. :(
| macintux wrote:
| > 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.
| throwawayboise wrote:
| I 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.
| microtherion wrote:
| The problem with tools that generate code is that they are
| often unidirectional. If there is no way to get code changes
| to propagate back to the visual model, the latter is likely
| to fall into disrepair pretty quickly.
| klyrs wrote:
| It could be possible to do something interesting in this
| space, where UML can be used generate template code, and
| later on, another tool could extract UML from the code,
| compare it to the baseline, and flag any discrepancies.
| From there, you can either sign off on the discrepancies
| (and replace your hand-made UML with the extracted one) or
| fix your code. Bit of a kludge, but at least automatic
| verification is possible unlike documentation
| kingsuper20 wrote:
| Hey, I remember that. Code generation is cool in that you
| have now made it an upstream part of your tool chain. No
| changes allowed at the code level.
| chrisseaton wrote:
| > UML was the swan song of the classic waterfall SDLC gang.
| Agile and TDD came along and nobody looked back.
|
| Don't the UML and Agile and TDD 'gangs' overlap? Robert
| Martin has evangelised both.
| throwawayboise wrote:
| The difference I was trying to highlight is that UML (at
| least in my experience) was still very much focused on "big
| design up front" and production of design artifacts (vast
| numbers of diagrams) that agile and TDD approaches
| explicitly rejected.
|
| 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?
| chrisseaton wrote:
| But that's the point - how are the same group
| recommending massive complex paper designs up front, and
| also agile methodology?
| nick__m wrote:
| Opinions and ideologies change over time, here's an
| hypothetical timeline that explain your question
|
| ===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.
| chrisseaton wrote:
| Maybe I'm cynical, but it seems like these people are in
| a farcical cycle of repeatedly inventing some new master
| theory of programming only to find it's actually a
| disaster later a few years later and then to switch to
| something apparently diametrically opposed.
|
| 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 stressed by
| endlessly sprinting 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.
| michaelcampbell wrote:
| The intersection space in that Venn diagram is generally
| anotated as "$$$".
| 29athrowaway wrote:
| The modern incarnation of agile has very little to do with
| what is written in the agile manifesto.
|
| 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.
| tgaj wrote:
| > Also, developers can have a good approximation to what
| the customer wants, even without talking to the customer,
|
| 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.
| 29athrowaway wrote:
| The largest software companies in existence were born
| during a time when the role of product manager did not
| even exist.
|
| 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.
|
| https://youtu.be/4JVJdKnbZu8
|
| https://youtu.be/P4VBqTViEx4
|
| https://youtu.be/Y6P8qdanszw
|
| "We hire smart people to tell us what to do". - Steve
| Jobs
| diydsp wrote:
| Agreed. Original agile connected developers and customers
| through valuing sw features. Today's agile is whip-cracking
| with the value of features obscured from developers who
| waste customer time doing unjustifiable work. It's more of
| a social game than one that benefits customers, so it can
| not last forever.
| bakatubas wrote:
| I 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.
| seventh-chord wrote:
| I feel like my ideal workflow would be a middleground
| between doing the design up front and just jumping into
| coding. Before you start coding I feel like you don't have
| much of an idea of what problems you will run into,
| resulting in diagrams based on the wrong assumptions. But
| with code it's easy to loose track of the high level
| structure of what you are writing. Writing code, then
| diagramming the high level structure, and then going back
| to fix the code seems like a good way to go.
| bakatubas wrote:
| Absolutely! That is similar to artists doing thumbnail
| sketches to figure out the composition; then once things
| are reasonably worked out, the chosen composition can be
| worked onto the final canvas; then the details follow.
|
| 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.
| pjbk wrote:
| Granted, 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 wrote:
| I 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.
| michaelcampbell wrote:
| > I used one of those tools at one point, Rational Rose. It
| was possible to get it to generate code,
|
| 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.
| robertlagrant wrote:
| I used RR at Uni in the early 2000s. It felt very clunky even
| then. It was also a pig to use - somewhere along the line it
| become known as Crashional Rose.
| disordinary wrote:
| Yep, they taught us RR in uni in the early 2000s as well,
| this was in New Zealand.
| bryananderson wrote:
| Honeywell "automatically generated" all of the flight code
| for the James Webb Space Telescope using Rational Rose in the
| early 2000s. They were still trying to fix the code when I
| was at NASA Goddard in the mid-2010s.
| spaetzleesser wrote:
| Years ago I had a contract with IBM so I got Rose for free.
| It had really neat demos but once you started using it, it
| was basically useless or worse. You got a few stub classes
| and then spent the rest of the time keeping the models in
| sync with reality.
|
| I think only Clearcase had a bigger negative impact on
| productivity than Rose.
| pbhjpbhj wrote:
| My impression as an undergrad learning UML was that it gave
| an architectural level view - so the effort would go in at a
| different level of thinking, not just in a different part of
| the process?
| pvarangot wrote:
| Yeah it turned into that before kinda dying. Now in the
| "real world" those tools are only used for diagrams that
| explain what's called a "slice" of the architecture, but no
| one really gives a whole architectural view of a system on
| UML. Not even for a simple component.
|
| 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.
| makach wrote:
| I replaced UML with Archimate, I hated where UML was heading and
| the concept of dropping code/reverse engineering from source code
| - the idea was novel enough but definitively snake oil.
| Architecture is important, this is nicely achieved with Archimate
| imo. What works for me might not work for you. I still use some
| elements from UML but usually on a whiteboard as either use-
| cases, simple sequence charts or state diagrams. The code is self
| documenting.
| haolez wrote:
| There are some diagrams that I've more useful than others. My
| favorites:
|
| - 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
| DavidVoid wrote:
| Now that I think about it, sequence and state diagrams are
| pretty much the only programming-related diagrams I see used in
| the documentation at my telecom job. I even see sequence
| diagrams written in code comments from time to time, they're
| always appreciated.
| thiht wrote:
| Sequence diagrams are probably the most useful UML diagram. I
| don't know of a simpler way to specify and document workflows,
| no matter the scale (from function to whole system)
| nraynaud wrote:
| no, I got a recruiter contacting me for some UML thing recently.
| Well, it was the Paris metro company, so I guess UML is dead, and
| they just got their "UML project" together.
| boyadjian wrote:
| There was a big UML fashion in the company where I work, they
| even hired a specialist in the subject, did training. And a few
| years later the specialist left, and no one made UML anymore
| nitwit005 wrote:
| Past a certain scale it just seems easier to read text than
| visual diagrams, and since apps have tended to get more complex
| over time, we're reaching that scale more often.
|
| 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.
| unixhero wrote:
| UML failed because it kind of sucks, right?
|
| 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...
| Chazprime wrote:
| It's a great tool for those times I need to familiarize myself
| with a new codebase, but for my own projects it just becomes a
| pain to keep updated.
| jillesvangurp wrote:
| Agile killed off UML. Pre-agile, people were either doing really
| slow iterations (spiral development, rational unified, etc.) or
| just trying to do waterfall because that what people learned in
| school. Either way that meant obsessing over requirements for a
| while and then doing an actual design phase before you actually
| did any coding. And of course that required lots of diagrams and
| documentation; if only to give management some sense of progress
| (which to be fair was often the main point). UML merely tried to
| standardize that practice. And then IBM bought Rational around
| the same time the Agile Manifesto was signed.
|
| 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.
| adsharma wrote:
| Replace UML with python data classes. You'll be much happier
| AJRF wrote:
| Other people in this thread have expressed it, but the reason
| it's not useful is because most developers are doing something
| like UML, but it's not UML - so you get none of the benefits of
| the Unified part.
|
| 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.
| jameshart wrote:
| In my experience, when I see a good UML diagram I know I am
| seeing a picture of how someone thought something was going to
| work before they (or more likely _someone else_ ) actually
| built it. It might or might not accurately reflect how the code
| actually works. In particular constraints the diagram claims
| exist may or may not actually be enforced in the code. The UML
| diagram says a Foo only exists for the lifetime of the Bar that
| references it; well, this memory dump from production says
| otherwise, so I don't care what your diagram says, the code is
| what matters.
| musingsole wrote:
| The trick is to tie your UML to your code with a few scripts.
| After a point, if you're manually interacting with it, you're
| doing it wrong. A lot like the AWS console.
| lelanthran wrote:
| > The trick is to tie your UML to your code with a few scripts.
|
| How do you do that?
| 29athrowaway wrote:
| I do not think UML has died.
|
| 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.
| neilv wrote:
| I used to develop next-gen high-end OO CASE tools, and am big
| into systems analysis/design/etc., visual thinking and
| communication, etc.
|
| 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.
| jiriknesl wrote:
| I think, the biggest issue with UML is that it helps with things
| that doesn't need such a ceremony and doesn't help in things
| where you would need it.
|
| 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.
| [deleted]
| jameshart wrote:
| I don't get the example given here that shows three steps joined
| by arrows and claims that the diagram is ambiguous about the
| order of execution of the steps.
|
| 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.
| zorked wrote:
| Good riddance. UML is part of the infinite-complexity infinitely-
| layered culture around the Java language in the late 90's and
| early 00's. Where OO-supremacist "system architects" were trying
| to split software development into the first-class flying,
| conference-attending chosen few who could do modelling, and the
| unwashed masses who were to be replaceable, underpaid, be-glad-
| you-earn-more-than-minimum-wage outsourced code monkeys.
| pjmlp wrote:
| A culture born out of C++ and Smalltalk enterprise tooling
| before Java was even an idea.
| acdha wrote:
| Mentally I have this bundled in with 4GLs and the perennial
| visual programming environments, revolving around the idea
| that the act of coding was the expensive part rather than the
| application complexity.
|
| 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.
| nomercy400 wrote:
| Good thing we now have SCRUM for our code monkeys.
| bryik wrote:
| The UML specification is 796 pages[0]. It is amazing how humanity
| can take simple concepts like flow charts and inflate them into
| insane, hyper detailed legalistic rule books that almost no one
| understands or uses.
|
| 0 - https://www.omg.org/spec/UML/2.5.1/PDF
| hu3 wrote:
| If you complicate things enough you can sell consultancy and
| certifications.
| anthk wrote:
| Red Hat/IBM.
| rootusrootus wrote:
| Atlassian.
| r3dapple wrote:
| This also applies to modern IT security
| marto1 wrote:
| and as we all know - really complicated security models are
| the very bedrock of a sound and secure system.
|
| /sarcasm
| mynameishere wrote:
| On the other hand, where would we be today without:
| 13.5.11 A_signal_signalEvent [Association]
|
| ...that thing. These are men who really, really wanted to be on
| the PL/1 committee so many years ago. They missed their
| calling, like so many of us.
| rjsw wrote:
| You could also add in the page count for the specifications of
| SysML, DD, MOF, OCL, QVT and XMI.
| marto1 wrote:
| that kind of motivation can be summarized as "money" or "a lot
| of money". This combined with copious amounts of narcissism.
| danimal88 wrote:
| I never got the impression it had much life in it to begin with
| ch_123 wrote:
| My personal experience is that system-level architecture diagrams
| are useful (i.e. which service/application talks to which
| service/database/message queue etc.) but code/class level ones
| are not. As to why - because the code tends to change a lot more
| often compared with the overall architecture of a platform.
| Requirements change (or requirements become better understood),
| code is refactored once the engineers get a better feel for the
| structure they are solving, new tools come along, etc. Code level
| diagrams have a habit of going out of date quickly, or (even
| worse) discouraging people from making useful changes based on
| new information.
|
| To me, it seems that in their rush to criticize agile, the author
| failed to consider _why_ agile-like practices killed off UML.
| fatbird wrote:
| Ironically, UML diagrams are still very useful for their
| immediate purpose, whatever that is. I frequently use timing
| diagrams just for my own sake because having to articulate
| something always adds clarity, showing you where you were
| handwaving something in your head. It's the draw.io version of
| rubber ducky debugging.
| seanmcdirmid wrote:
| There were a bunch of academics in a certain rich EU country that
| dumped a lot of research dollars into UML (via their own research
| and their control of funding agencies and committees). That
| they've mostly retired by now probably has a lot to do with
| rapidly declining interest in UML.
| josalhor wrote:
| My teacher in Software Engineering that "taught us" that UML is
| used everywhere in CS and business. Looking up their CV, they
| only had two years of experience outside academia, and that was
| 20 years ago.
| sitzkrieg wrote:
| its still very alive in the MBSE world of SysML a superset,
| supported by many tools
| Rochus wrote:
| And at least as useful ;-)
|
| 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-...
| rjsw wrote:
| STEP (ISO 10303) is moving to use SysML to define the models
| for the collection of standards.
|
| Part of the reason is to be able to use visual tools instead
| of defining everything using text.
| Rochus wrote:
| The versions of ISO 10303 I'm using are based on EXPRESS
| and EXPRESS-G; didn't see any SysML there; this even
| applies to ISO 10303-233, the systems engineering AP of
| STEP. There is a tendency towards RDF/OWL driven by the ISO
| 15926 series though.
| rjsw wrote:
| I wrote "is moving". Nothing has been published yet that
| has been developed using SysML, the first standard will
| be the next edition of one of ISO 10303-242 or 239 or the
| first edition of ISO 10303-243.
| Rochus wrote:
| References? Why should they do that?
| rjsw wrote:
| You can look at the minutes of any TC184/SC4 meeting for
| the last couple of years for a reference.
|
| I already explained why, people want to use visual tools.
| Rochus wrote:
| Can you please be specific and provide us with current
| links or official documents which support your statement?
| I know that there are some exponents (mostly with
| computer science, not systems engineering background) who
| don't like EXPRESS and would rather use SysML, but these
| are just opinions, not the official roadmap which affects
| the ISO 10303 standard series. It's possible that there
| will be an official mapping from EXPRESS to SysML (as far
| as possible) in future to automatically generate SysML
| diagrams (in addition to EXPRESS-G). But it's very
| unlikely that SysML will replace EXPRESS or be used as an
| equivalent alternative. EDIT: I remember similar
| discussions in the nineties when UML supporters
| questioned the appropriateness of EXPRESS.
| rjsw wrote:
| There are some tools [1] to allow the "harvesting" of
| existing EXPRESS models into SysML and to export XSD,
| JSON or EXPRESS schemas for delivery with the published
| standards. There will also be a way to map between
| existing models and new ones. The driver for this is to
| try to provide a way for ISO 10303-242 and ISO 10303-239
| to interoperate better.
|
| SysML is also replacing the use of IDEF0 for the high-
| level requirements diagrams, finding IDEF0 software was
| getting too hard.
|
| [1] https://sourceforge.net/projects/canonical-xmi-tools/
| rubyist5eva wrote:
| UML sucks because it takes forever and if your software changes
| you have to change your UML. I just use tooling that allows me to
| generate diagrams on the fly based on the existing code.
|
| In the planning phases I just use Draw.io, but that always ends
| up out of date and irrelevant once the system actually exist.
| waprin wrote:
| UML is closely associated with Object Oriented programming. In
| the 2000s, OO programming was all the rage, and having a mental
| notebook of "design patterns" was considered the hallmark of a
| real software engineer.
|
| 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.
| tarkin2 wrote:
| UML died alongside the waterfall method. UML, especially defining
| the method names et al, before you coded anything was an extreme
| of the waterfall method. I think generating UML from code could
| have been useful. But I was much more likely to grasp more of the
| system from a paragraph or two or well-written text. Well-written
| UML rarely helped. Roughly sketched boxes with arrows and a bit
| of text are the most useful.
| marto1 wrote:
| I mean, I hope so. Never really met anyone overly excited about
| it or any of it's applications. Plenty of people on the "hate it"
| side, though.
| JoshCole wrote:
| A lot of others have talked about the UML aspect of this post,
| but I want to speak to something that was more in the latent
| space of my reading of the post and its dislike for agile trends
| and a kind of supposition of something being lost by losing UML.
|
| 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.
| quux wrote:
| I think the only UML diagram with real merit is sequence
| diagrams. I use those all the time.
| deanclatworthy wrote:
| I think all of us who studied CS (at least over 10 years ago, no
| idea what's being taught now) hated UML.
|
| 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.
|
| [1] https://plantuml.com/sequence-diagram
| pjmlp wrote:
| Like every kind of these questions, not at all and is pretty much
| alive in corporations.
|
| 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.
| throwaway931245 wrote:
| What is UML?
| zozbot234 wrote:
| User Mode Linux. An old project that was in the same space as
| present-day Xen and KVM.
| jbverschoor wrote:
| Unused Mainframe Linguistics
| jbverschoor wrote:
| Luckily I have enough karma to afford these kinds of comments
| :-D
|
| I never liked the arrow-direction in uml
| simonw wrote:
| Unified Modeling Language:
| https://en.wikipedia.org/wiki/Unified_Modeling_Language
| ssn wrote:
| No, unfortunately is a sign that documentation is not being take
| seriously.
| Marazan wrote:
| UML's problem is that it is boxes-and-lines.
|
| 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.
| xyst wrote:
| speaking of uml, there was a general "software engineering"
| course at my uni and there was a section on UML diagraming. I
| remember creating these absolutely beast UML diagrams that looked
| more like spider webs. It was fun, but absolutely useless in the
| real world lol
| phoe-krk wrote:
| Anectodal data point: no, it hasn't. I still use it in every
| project that we make at my dayjob, including system
| documentation, implementation proposals, communicating design
| choices to other people.
| tyingq wrote:
| That's what I tend to see as well. Used around documentation
| and drawings. Used much less in any context around real
| code...little code->uml, and almost no uml->code.
| zozbot234 wrote:
| Doesn't Doxygen give you code-> UML structure and
| collaboration diagrams pretty much for free? It also supports
| a wide variety of languages.
| slim wrote:
| No. I use it everyday. On paper. On white board. Whenever I want
| to think about (foreign) business logic, alone or in group.
| domano wrote:
| Like actual UML or UML-ish diagrams?
| slim wrote:
| He calls it masala in his post. But you know what? Masala is
| just UML. Because the L stands for language, and languages
| evolve when used (or die when not used, not when used
| differently)
| notatoad wrote:
| by that logic, i can start using braces in python and it'll
| still be valid python because languages evolve.
| jgilias wrote:
| You mean, using something like bython[1]?
|
| [1]https://github.com/mathialo/bython
| slim wrote:
| Never say never :)
| ozim wrote:
| That is picking on the details.
|
| 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".
| MAGZine wrote:
| i don't think it is. the article isn't saying the
| diagramming is dead. it's saying uml is dead.
|
| 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.
| k__ wrote:
| Probably a bit like REST.
|
| 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.
| blowski wrote:
| That's the real question.
|
| 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.
| perfect_kiss wrote:
| I don't agree with the posting. In my opinion, UML had rebirth in
| 2010s with the growth of popularity of PlantUML. See that
| PlantUML is referenced already in this thread, and to positive
| sentiments already expressed, I can add the notion that PlantUML
| fits much better, than most of earlier UML related software, for
| the purpose of network modelling. While original UML standard was
| not specifically designed for representing networks, PlantUML has
| network diagram type built-in. And extensibility of PlantUML
| allows to cover many use-cases beyond that. I imagine that with a
| certain amount of tenacity applied, it would be possible to
| create PlantUML library for "masala diagrams" as well. Also,
| "agile" shops usually love that tool, since it requires minimal
| learning curve for any person on a team to start producing nice-
| looking diagrams.
| seattle_spring wrote:
| It was dead when I learned it in college in 2006.
| [deleted]
| azeirah wrote:
| Standardised UML was never something for me, sketching diagrams
| loosely inspired by UML definitely was.
| mycall wrote:
| I learned UML years ago but found PowerPoint superior for
| explaining what needed to be done. So much easy to sketch using
| PPT than even Visio which makes me pull my hair out.
| jameshart wrote:
| Yup, I've always referred to UML as 'a formal standard for
| back-of-the-envelope sketches'. It demands too much precision
| and rigor to be used during the early parts of a project when
| you want to just get people on the same page about roughly how
| things should be structured without baking in assumptions too
| early. Then in the later part of a project when you're talking
| about modifying an existing system, reexpressing the existing
| semantics accurately in UML first demands unnecessary pedantry.
|
| 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.
| adjkant wrote:
| This is the real answer. The effects of UML will live on
| forever, but a formal language for it has been dead for a long
| time in common use, though some of course will still use the
| exact formality.
|
| 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.
| jamestimmins wrote:
| I've been trying to build diagrams to familiarize myself with
| new systems, but I wish there was a UML-lite that worked well
| for generalized diagrams in Python.
|
| Instead, I spend 70% of the time just trying to figure out a
| good diagram approach.
| billfruit wrote:
| Why is this sentiment so prevalent. I'm thinking more and
| more that simplistic and vague informal diagramming is a
| great source of confusion.
|
| 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).
| MsMowz wrote:
| In my experience (startup product development), product
| requirements and constraints are constantly shifting in
| order to support new use cases. In my practice, that has
| translated into only formalizing specifications after the
| fundamental needs of a system are set in stone, which is
| usually after release. When I've worked on contract-based
| projects, it's been much easier to formalize beforehand,
| but I suspect most developers on HN are involved in active
| product development.
| billfruit wrote:
| Thats true, but at least before implementation, the
| behaviour to be implemented should be known to some
| extent. UML Statecharts remain a good method to document
| behaviour.
| ajuc wrote:
| Documenting implementation details is often exactly what
| you don't want.
| emddudley wrote:
| By the time you are specifying things in such unambiguous
| detail you should be writing code and iterating.
| danielbarla wrote:
| The reality is that humans have a rough sweet spot for the
| amount of complexity they can reasonably consume, and a
| high-level, somewhat vague diagram that has been cherry
| picked by someone who intimately knows a system is a great
| introduction.
|
| 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.
| jerf wrote:
| I don't find it a source of confusion, because my boxes and
| lines diagrams are explicitly meant to be _sketches_ , and
| are presented as such.
|
| 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.
| rsclient wrote:
| Because the more mathematically rigorous and pure a
| description is, the more likely that your programmers won't
| carefully read the spec, or won't fully understand the
| exactly meaning of the UML arrows.
|
| 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.
| [deleted]
| ajuc wrote:
| > Why is this sentiment so prevalent
|
| 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"
| lou1306 wrote:
| > simplistic and vague informal diagramming is a great
| source of confusion
|
| 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
| toomanyducks wrote:
| My AP CS class covered UML, I haven't seen it anywhere else.
| Diagrams, yes, quite frequently. UML, never once.
|
| I put the bare minimum of time into studying UML, and I'm glad
| I did.
| azhenley wrote:
| That's how I think of it too. It's more like pseudo code for
| throwaway diagrams, not living documentation.
| mr_tristan wrote:
| I find that I mostly use diagrams for "explanation
| documentation". This is by far the best description:
| https://documentation.divio.com/explanation/
|
| > 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.
| mrweasel wrote:
| Same here. I still think UML is a great tool, but few have the
| need to follow the standard to the letter. Often I don't fully
| understand a problem before poking at it for a while.
|
| 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.
| peter_retief wrote:
| Same here, UML was nice to create a visual flow of a project.
| Never actually generated any code from the diagrams.
| epx wrote:
| UML acronym means "programmers are just typist monkeys and should
| be paid peanuts".
| sgt101 wrote:
| The problem I found was that no matter how careful we were in
| drawing the UML there was always one box on the diagram that
| turned out to be the "pandora box". When someone started work on
| it it suddenly became apparent that all the complexity of the
| system lurked within - and we could never be sure which one it
| was or how to get rid of it/them.
| wirrbel wrote:
| I think it highly depends on your work context, wouldn't exactly
| call it dead but firmly in the trough of disillusionment. Funnily
| enough, I think the author's analysis is a bit off, or rather
| misses essential points. They somewhat blame the procedural
| changes for a demise of UML.
|
| 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).
| neatze wrote:
| How does FMC compare to SysML?
| ncann wrote:
| In my experience, any attempt to describe/document/plan a system
| using UML inevitably turns into an outdated mess that no one is
| willing to waste time on updating. Eventually it becomes worse
| than useless since it contains objectively wrong information.
| notacoward wrote:
| "Most developers suck at X" is not always a problem with X.
| Someone wrote:
| I don't think the "using UML" phrase is significant in that
| statement.
|
| 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.
| ajuc wrote:
| > yet everybody who encounters a new large code base starts
| drawing diagrams
|
| 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.
| TeMPOraL wrote:
| On that note, I really wish we had tooling for automatically
| generating diagrams from existing code. Kind of an
| interactive query language:
|
| "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/i
| mg-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.
| Viliam1234 wrote:
| I usually start drawing diagrams because the existing ones
| are difficult to read.
|
| 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.
| heavyset_go wrote:
| > _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._
|
| This still comes to a head with Unreal Engine Blueprints.
| zozbot234 wrote:
| > 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.
|
| 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.
| Kwpolska wrote:
| > 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.
|
| [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.)
| INTPenis wrote:
| Actual engineers still use it. Not the ones we started calling
| engineers because they know a bit of Linux and kubernetes.
|
| 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.
| ex_amazon_sde wrote:
| I've never seen anybody using UML in Amazon, despite its
| culture for documentation, charts, metrics and diagrams.
| 8note wrote:
| I see bits and pieces of things that can be considered UML --
| sequence diagrams, data models, the odd class diagrams and
| the like
| nexuist wrote:
| Not sure why you included the necessary gate-keeping. If you do
| the same things engineers do, you are an engineer. You may not
| be a good one, but you still count.
|
| > 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?
| INTPenis wrote:
| The term engineer means different things in different parts
| of the world I guess.
| lainga wrote:
| >If you do the same things engineers do, you are an engineer
|
| A very American perspective!
|
| https://en.wikipedia.org/wiki/Canadian_Council_of_Profession.
| ..
| nexuist wrote:
| OP said engineer, not _licensed_ engineer :)
| 8note wrote:
| The Canadian perspective is that all engineers are
| licensed engineers. An unlicensed engineer is illegal
| aneutron wrote:
| I would not love to work with you. That's for sure. I'm 24
| years old, one of "those they started calling engineers because
| they know a bit of linux".
|
| 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.
| INTPenis wrote:
| Uh just to be clear, I am one of those devops engineers who
| taught themselves.
|
| 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.
| njacobs5074 wrote:
| UML has been on life support for a long time because it served no
| real purpose for either engineers nor business users.
|
| 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.
| codeulike wrote:
| I like the concept of 'Masala diagrams' that OP introduces - I've
| drawn these a lot, and the UML-trained part of me is always
| slightly uneasy that I'm combining (say) data and process flow on
| the same diagram, or that some of my boxes are physical machines
| and some are programs, etc. But the thing is, you shape your
| masala diagram to communicate whatever the thing is you want to
| communicate. You'd need 3 or 4 UML diagrams to cover the same
| thing, and no-one would really care that you'd bothered to keep
| to the conventions.
| bccdee wrote:
| IMO diagrams work best in tandem with actual docs. The diagram
| is an abstract -- you glance at it to get a high-level
| understanding, and if you need to deal with the details you can
| look at the writing. UML always gives me a headache; I hate
| having to squint at a diagram to deduce details that I could
| just be reading about.
| [deleted]
| codeulike wrote:
| _IMO diagrams work best in tandem with actual docs._
|
| "IMO diagrams" are my favourite type of diagram
| plank_time wrote:
| UML is the same line of thinking as J2EE which is the worst thing
| I've come across in my 25+ year career. J2EE took software
| complexity and made it not only more complex but catastrophically
| tedious. And then the "experts" were no longer software
| developers but bureaucrats. It was the perfect way to destroy
| Java and enterprise software.
|
| 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.
| rytis wrote:
| There's quite a lot of hate in the comments for UML is seems. And
| while a lot of it is quite valid, I have to say that sometimes I
| miss _some_ of what UML could do, especially in form of
| documentation. Sometimes a simple sequence diagram is able to
| communicate the behavior of a system much clearer than 10's of
| pages of disjointed prose... Just my opinion.
| jugg1es wrote:
| Nothing is stopping you from creating diagrams, but UML is not
| required to create useful diagrams. Most concepts can be
| diagrammed using only boxes and lines.
| jhayward wrote:
| This could only be said by someone who hasn't sat through
| their Nth architectural overview where half the time is spent
| defining just exactly what was and was not intended by a
| particular line+arrow between two boxes when a simple
| sequence diagram would have been crystal clear.
| jorl17 wrote:
| Sequence diagrams are the one UML diagram I regularly still
| produce to communicate behavior both to other developers and
| less technically minded people. I personally find them great
| (as long as you don't get carried away in very minute notation)
| detaro wrote:
| I don't think it'll die entirely anytime soon, but certainly it
| has lost in mind-share - especially in the fully by-the-book way.
| Vaguely UML-like adhoc notations are way more common, and will
| survive even longer. (And my interactions with people aiming to
| do it _properly_ have involved more ambiguity than would expect
| from a good standard)
| pachico wrote:
| What did I miss? I use it every day and it works perfectly!
| sli wrote:
| My entire experience with UML was as a high school aged kid who'd
| just found out about it, but despite my best internet searching,
| could find absolutely no resources on learning or using it. So I
| just gave it up and this post is pretty much the first I've heard
| about it since c. 2002.
|
| So... yeah, sounds like it. Everyone I know that needs something
| UML could do just uses Draw.io these days.
| galaxyLogic wrote:
| UML started from the premise that software is a model of the
| world. But in fact what software really is, is a model of a low
| level program in assembler or binary we want to construct. But
| the proponents of UML didn't realize that either you must model
| the real world or you must model software. They are not the same.
|
| "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.
| spaetzleesser wrote:
| In my view one of the biggest problems of UML was that it's ugly
| and not very intuitive. For a while I jumped on the UML bandwagon
| and developed a lot of diagrams of the various types. Turned out
| that even very experienced developers didn't understand them not
| even to mention less technical people.
|
| 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.
| FpUser wrote:
| Rational was set to conquer the world. Never good idea. However I
| still use some of their ideas and StarUML diagramming tool to
| help document preliminary design, use cases, deployment etc. It
| makes communicating to non tech persons way simpler.
| mmcnl wrote:
| > In a model in which you pour user stories into a sausage
| machine, and you get a demo at the end of it (or a feature
| production release in a DevOps shop!) there is no room for
| purposeful, structured problem analysis anymore.
|
| This couldn't be further from the truth.
| major505 wrote:
| This is what happens when writing documentation owuld take the
| same or more time than writing code. We all see that most "no-
| coding" auto generating approaches to software development did
| not work except for simple solutions, and the irony was that the
| people who had time and manpower for uml where the one with most
| complex need of software.
| TheJoYo wrote:
| GitLab supported Mermaid.js rendering for a while but last I
| checked that was broken. That showed the most promise for a
| practical use of UML.
|
| 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.
| darkerside wrote:
| UML suffers from false precision. Nobody cares about most of the
| specific rules and grammar of the language because the output is
| designed to be generally readable by a lay audience. The time
| your spend making your diagram compliant with UML is better spent
| making and remaking good general diagrams.
| bastawhiz wrote:
| Exactly. Tools to build visually appealing diagrams well
| appeared. I remember how _fun_ it was diagramming in Visio for
| the first time.
|
| 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.
| chestervonwinch wrote:
| > 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?
|
| 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.
| bastawhiz wrote:
| They're not modeling code in many cases, they're modeling
| processes, products, and user flows. If you're building an
| app, your diagram is going to look a lot more like the
| things your users see in order rather than the code to make
| those UIs appear. E.g., the code for react-dom-router
| routing is going to look very different from the actual
| navigation patterns built on it (tree structure versus
| linear flow).
|
| The primary need for diagrams is drifting further from the
| use case you're describing.
| vlovich123 wrote:
| I'm of the opposite predilection. I want to be able to manage
| my architectural diagrams in code review. I like having a
| tool where I can edit it in one pane and have the diagram be
| a live preview beside it. Ideally the wiki tool would be able
| to render it.
|
| 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.
| chestervonwinch wrote:
| > PlantUML is great but suffers from having ... ugly
| default style ...
|
| I quite enjoy the C4 diagram stylings:
| https://github.com/plantuml-stdlib/C4-PlantUML
| vlovich123 wrote:
| That's interesting. Does it have an atlassian plugin?
| mjul wrote:
| I think it was Kent Beck that proposed the tongue-in-cheek
| Galactic Markup Language, GML as his preferred alternative. It
| has very clear semantics: a box is a box and an arrow is an
| arrow.
|
| 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.
| layer8 wrote:
| Nevertheless it would be useful if everyone knew which
| "arrows" mean subtyping vs. reference vs. ownership vs.
| instantiation, and which boxes mean action vs. object/class,
| etc. If you only have "arrow" and "box", you have to explain
| what you mean by them in the specific instance every time.
|
| Also, UML does have some nice graphical notation like
| ----(o---- to denote interface and implementation (sockets
| and plugs).
| acdha wrote:
| I'd add generating diagrams from the real code, database
| models, etc. as an alternative, too. General high-level
| diagrams don't need the level of detail which UML requires but
| it's inevitably not enough detail or accurate enough to
| understand the system using just the UML diagrams, so you end
| up with a bunch of expensive time wasted creating diagrams
| which don't satisfy either audience.
| PurpleFoxy wrote:
| My IDE had that feature and on all but the most basic
| project. The diagrams would come out so large you'd have to
| zoom 100x to see anything.
| martin8412 wrote:
| UML is just all around horrible. I can't think of a single
| situation where it provides any benefit. It is a huge pain in
| the ass to the developer, and it just inspires false confidence
| in managers
| wirrbel wrote:
| A problem of UML is, even worse in UML 2, that it was developed
| for UML tooling vendors (IBM rhapsody, Enterprise Architect,
| etc.). It is as if we had one compiler vendor design and
| promote a Universal Programming Language, declare it as an
| industry standard that supersedes all alternatives and has in
| their interest to lock-in all programmers.
| elzbardico wrote:
| And the compiler vendor is IBM
| billfruit wrote:
| Is there a general diagram with the expressivity of UML
| statecharts?
| ajuc wrote:
| almost uml statecharts that ignore some rules where they
| don't matter
| zozbot234 wrote:
| Petri nets, especially if extended w/ hierarchy. These seem
| to be more elegant and expressive than plain FSM's as
| extended in the UML approach.
| tyingq wrote:
| Graphviz dot maybe?
| Daishiman wrote:
| Also the level of detail that UML demands _always_ turns out to
| be imprecise once coders end up implementing specs. So it 's a
| place where enough formality is required to be a PITA to model
| but where it falls just short enough of the specifics a
| programmer will need once they get to actually building out the
| product.
| [deleted]
| 8note wrote:
| This sounds like UMLs job is to be drawn after project is
| complete for documentation/refactoring, rather than as a
| design tool.
|
| I think the proper comparison is then a suite of test code
| [deleted]
| forinti wrote:
| I always treated UML as a window into the domain, not as a
| precursor to the code.
|
| 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".
| lordnacho wrote:
| I was gonna say just this. If you are able to specify how the
| objects are related, why not just code up the skeleton?
|
| Similar issue in UI design. Why draw up the mock when you
| could just make a static webpage?
| throwawayboise wrote:
| The idea was if you found that the model was lacking in
| some way, you would update the model and regenerate your
| code. In practice that just didn't work, or at least it
| didn't result in saving any time or in producing better
| software.
| hackbinary wrote:
| And now we have MS Flow. And other "codeless" programming tools.
| neovive wrote:
| I tried UML years ago with little success. I recently started
| working with BPMN 2 with some success -- swimlanes are easy to
| explain and make sense to most people. ERD's are still my
| favorite notation and really stood the test of time!
| k__ wrote:
| I mostly use it to understand code-bases.
|
| 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.
| dragonwriter wrote:
| Three things happened to UML:
|
| 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.
| robertlagrant wrote:
| It's not been my observation that the overlap is that big,
| having done lots of BPM work using BPMN in a former life. BPMN
| is for describing much higher level processes than what UML is
| for.
| dragonwriter wrote:
| > BPMN is for describing much higher level processes than
| what UML is for.
|
| 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.
| nickkell wrote:
| How did you like it?
|
| 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?
| ok123456 wrote:
| There's a impedance mismatch between UML and actual programming
| languages. Idiomatic python is different from idiomatic java, and
| trying to make UML as it was originally intended, to be a
| detailed, formal specification of a program, is quite at odds
| with that. You either end-up having to ignore most 90% of the
| diagram, only using the high-level details, or you end up with
| programmatically generated garbage code.
| adriancr wrote:
| I still see it used and use it myself.
|
| 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.
| aidanr wrote:
| UML as a way of detailing the low level implementation of a
| system was, IMHO, a really bad idea. I say that as someone who
| once drew up all the GoF patterns in UML in Borland Together and
| then tweaked the generated Java code to do have running Java code
| for what the patterns said.
|
| 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.
| slver wrote:
| UML was propped up (and still is) by universities, but it was
| never big in practice.
| k__ wrote:
| I think, some diagrams are nice tools, but the way we learned
| it at university was overkill.
|
| We had whole semester long classes solely focused on designing
| systems with UML.
|
| In my job I never did this ever again.
| azhenley wrote:
| I think it was made big by Rational and some bigger name
| consultants.
| yrgulation wrote:
| In theory, UML diagrams sound good. In practice, having to
| maintain them is PITA. I quickly abandoned them as soon as i went
| above 10 classes, which even a basic OOP codebase will exceed
| quite early on.
| k__ wrote:
| Yes.
|
| It's nice to ge an overview, but I don't bother to maintain
| these diagrams.
| mszcz wrote:
| In my college years I've been told a lot of things by my profs.
| ORMs will kill RDBs, UML is the shit, Agile is the future of all
| software engineering etc. I could never _see_ most of those
| things happening but always assumed that they 're smarter so they
| must know what they're talking about. It's kind of satisfying but
| also profoundly sad that they were both wrong and failed to
| instill a reflex of questioning authority in their students.
| nine_k wrote:
| UML has a few good parts: sequence diagrams or use case diagrams,
| for instance.
|
| These few good parts can be used, or lifted from UML, without the
| rest of the UML baggage.
| muterad_murilax wrote:
| So, is that RIP or RUP?
| Anon84 wrote:
| Was it ever alive, really?
| ridaj wrote:
| My personal view: kill the garbage that is UML with fire, and all
| the attempts at formal modeling. Design is too rich of a field to
| be modeled formally.
|
| 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.
| birdyrooster wrote:
| Nope, I still use it, and many others too, for sharing design
| ideas.
| mkl95 wrote:
| These days UML is the kind of thing I mostly expect to find in
| xkcd strips. I have been writing software for a few years and I
| haven't seen anyone use it non ironically outside of academia.
| TruthWillHurt wrote:
| It's alive and well in enterprise projects where Solution
| Architects need to micro-manage frequently-replaced, Acceptance-
| Criteria-driven, non-thinking contractors.
| thomasfl wrote:
| Sequence diagrams is actually good. The initial idea was improved
| before it became a part of UML.
|
| https://en.wikipedia.org/wiki/Sequence_diagram
| pvarangot wrote:
| Yeah came here to say that. I use sequence diagrams a lot to
| illustrate complex processes before starting to implement
| components and stuff like that. But they were "co-opted" by
| UML, the idea is older than the whole mega-effort to make UML a
| thing and automate software engineering.
| mark_l_watson wrote:
| I do-wrote a UML for Java book with Paul Harmon, many, many years
| ago.
|
| Now, the only UML that I use are Sequence Diagrams - a favorite
| notation for expressing time based things.
| disordinary wrote:
| The reason we stopped with UML and other front heavy planning
| methodologies is that what we planned was always wrong.
|
| 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.
| Oddskar wrote:
| But what was perhaps lost along the way was communicating inner
| workings through something else than code.
|
| 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.
| disordinary wrote:
| Sure, but you don't have to go as heavy handed as UML. You
| have to wonder if a visual diagram is the best way to go into
| detail or should we use other ways of delivering that
| information?
|
| 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/dotAsse
| t/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.
| FinanceAnon wrote:
| I think the type of software that is being written has changed
| over time. In the past, companies had to write complete
| software that would be shipped on a CD - you cannot deliver an
| incomplete product and then change it later. Nowadays, majority
| of the software lives online and can be redeployed in a short
| time. Delivering early and often is possible now, but it wasn't
| in the past for majority of the projects.
| emperorcezar wrote:
| > Software projects always used to go massively over budget,
| were delivered late, and usually didn't meet the customers
| requirements anyway.
|
| I feel like this is still the case under "Agile"
| disordinary wrote:
| Sure, but agile is about breaking up work into small chunks
| and showcasing value in those small chunks. If you're doing
| it properly you'll be able to look at your velocity and know
| that you're falling behind schedule. Or, your customers will
| be able to see early that the thing your building doesn't
| suit their needs.
|
| 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.
| zozbot234 wrote:
| > We solve the complexity problems by breaking a project down
| into (as he says) "pizza team" size components
|
| 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.
| suzzer99 wrote:
| Exactly this. You never know your problem domain as well as you
| think you do.
|
| 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.
| 1ris wrote:
| I think uml is not a efficent way for me to pick up information.
| I learn them in the university and all, but don't think i
| actually used them really on my jobs. When I look up a design
| pattern, I try to understand it from a uml diagram, but almost
| immediately quickly jump to wikipedia for example code, as i
| consider it way more digestible. Not a coincidence, since i deal
| with code every code, with uml diagrams almost never.
|
| 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.
| segmondy wrote:
| sequence diagram is a great way to understand events between
| components/systems more so than diving into the code base.
| mattlondon wrote:
| I don't know about the rest of it, but sequence diagrams are
| alive and well and are basically in pretty much _every_ design
| doc I write and read.
|
| 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.
| indymike wrote:
| The problem with UML is that it could only represent certain
| functionality... and counted on code generation / translation to
| make it happen. It was an extra step. It was much more useful for
| analyzing and diagraming code, but that too was limited by
| whatever analysis was being done to generate UML.
| atum47 wrote:
| I started college back in 2016. I saw uml from day one. Never
| actually used it outside college. We used a lot of those tools
| that can generate diagrams from code and vice versa, but I
| personally never liked it.
| edgarvaldes wrote:
| Whats the better alternative, if any?
| dexwiz wrote:
| UML are blueprints, but blueprints are not the thing, just like
| maps are not the land. Talk to anyone in construction and their
| first complaint is often the blueprints are wrong. They may have
| missing or extra space, call for impossible things, changed since
| the project began, or be flat out wrong. Whether the blueprints
| are actually wrong or we're not followed is up for debate.
|
| 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.
| danellis wrote:
| I don't remember all of UML anymore, but I still use sequence
| diagrams, activity diagrams and state diagrams. Using something
| standard is just easier than having to think about how to
| represent something, and then explain your representation to
| someone else.
|
| 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.
| darepublic wrote:
| Rational rose anyone
| andi999 wrote:
| I think the big hope for UML was code generation, so UML->code,
| but the problem was, when manual fine-tuning of the generated
| code was needed, there was no functioning process of code->uml.
| superjan wrote:
| Why would I spend an hour on buiding a diagram to generate code
| if I can type the same code in five minutes? I can read both.
| This is from real world experience with Rational tools.
| Nasrudith wrote:
| I suspect the idea was to lower the skill ceiling to make it
| accessible to non-programmers or more cynically in a belief
| it would cut labor costs. It doesn't work out that way but
| overspeccing the wrong details is a persistent temptation,
| perhaps related to psychology of the leaders for reasons
| similar to micromanaging.
| andi999 wrote:
| Either that, or probably thinking about huge systems with
| uml diagrams in the size of the last supper.
___________________________________________________________________
(page generated 2021-04-25 23:00 UTC)