Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
foox674y@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? -
foox674y@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). -
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". -
foox674y@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. -
foox674y@Lucky-Loek thanks for your opinion
I agree, it doesn't need to be perfect UML but it helps to visualize ideas -
@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. -
foox674y@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)
-
@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. -
a few years late, but the 90s called, it wants its corporate executive flowcharts back.
Related Rants
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 😁
question
collaboration
uml
architecture