3
foox
3y

Talking about software engineering. probably everyone has a slightly different understanding of it, but I wonder who is still using UML or similar tools.
I'm asking cause I see only few who are capable of using it.
There might be tons of other ways of achieving things for what UML is meant for, but I got the impression that software designing /architecture isn't a thing at all. It's not only that I see a lack of collaboration efficiency, but I'm also afraid that it's more about hacking things together (maybe even by just smashing SO comments together)

Thanks, looking forward to read your opinions !

PS: if my suspicion was correct, than this would have been a rant 😁

Comments
  • 0
    @halfflat thanks for your opinion.
    That's somehow what I expected to read.
    IMO even in a small team its crucial for collaboration. Think most teams do not really experience it though, guess everyone has its own domain and only a few interfaces.
    Just can tell how our team improved by reducing boundaries and working closely.
    Additionally, knowing about UML and design patterns helps to solve already solved problems in a proven way. (just had good times extending some functionality by simply plugging in a new command into command pattern).

    Maybe it's also different in other domains?
  • 0
    @halfflat totally agree 👍
    And this answer shows clearly what you're talking about. Thanks!
    Template meta programming and related topics are equally important to me, though they are pretty language dependent (correct me if I'm wrong).
    But Ja, having someone applying who understands both feels to be super rare (personal experience only).
  • 2
    I think UML is fairly bloated and has way too many rules and diagrams to remember.
    But, I found that I can communicate my thoughts and nuances to my colleagues so much better when I draw them out. It automatically looks like UML since that's what everybody learned in and semi-understands.
    Instead of spending weeks communicating the intricacies of my thoughts, I can now do it in 10 minutes and all my colleagues understand what I'm saying. And they can just edit the drawings when they have better ideas.
    So... I think UML is a bit too much but I really appreciate the value of a common understanding when drawing out designs.
  • 2
    I learned UML, and design patterns.
    My experience is - if you need a UML chart - then you are not Agile. Problem right there.

    The way I look at it - UML is a Waterfall concept, born from the need to create an extensive documentation before implementation. True - working this way will avoid many many problems down the road, but the upfront cost is very high, and when used in Agile for MVP, will create a tech debt overhead of - "need to update the UML charts now after the rollout".
  • 1
    @magicMirror thanks for your opinion

    must say I cannot totally agree. Saying UML isn't something you can use in agile makes me wonder whether we have the same understanding. As soon as you have to use other components, interfaces and sequences play an important role. It's not about documenting and keeping it up to date necessarily, it's more about getting a common understanding 🙂
    In my opinion that's one of the fundamental misunderstandings of the agile manifest. It's not necessarily about documentation but having a language for individuals and their interaction.
  • 1
    @Lucky-Loek thanks for your opinion

    I agree, it doesn't need to be perfect UML but it helps to visualize ideas
  • 1
    @foox It can fit - But like any other document you create during the dev process, you need to maintain it.
    Agile does not like to maintain stuff that does not "give value to the client".
    There are a few cases where a UML charts could be helpful - Say, when building an API to be consumed by a Client. But for most cases - a flow chart, or a unitest/code sample is much much better.
  • 1
    @magicMirror I'm more thinking of standing in front of a whiteboard and trying to make up a design with the team (let's say in a Sprint planning 2 meeting or something similar). But get your point and agree. We tried to maintain UML as part of our documentation in former companies where we failed to do so. BTW I would count flowcharts to the set of UML diagrams (activity diagram)
  • 1
    @foox Whiteboards are nice.
    I prefer not to use them, unless I am explaining an existing something that might not "stick" to the team.
    When we do a brain storm, I prefer a tv screen, with something like lucidchart, or omnigraffle - and the result goes directly in the relevant Jira ticket.

    UML as a comprehensive documentation solution (coupled with the right IDE bindings) is an awesome powerfull tool. But rarely used correctly. I have never seen it in the "wild". Maybe a flow chart.
  • 0
    a few years late, but the 90s called, it wants its corporate executive flowcharts back.
Add Comment