Hi! you haven't mentioned two very crucial things: - you can't "plan" the thing you don't know. Business requirements are the exact example of such thing - "change". Not actualized class diagrams are not useful (not to say are harmful). And modern IDEs make writing code MUCH faster then fixing diagrams. Just an example: renaming a method in ALL classes takes less then a second - finding and renaming it in diagram - takes hours.
Thanks for the feedback! I agree, class diagrams are just one tool in the toolbox, and adapting to evolving requirements is crucial. Those should have been in there. as for planning what you don't know - even after decades in the field I still don't know the best solution for this other than to have a flexible design.
Good feedback thanks I was actually going for a story approach that presents techniques or approaches to the general public or junior level devs Let me review and see how to improve
@@theseriouscto yes, you could fit so much more into 4 minutes. I am a layman, not even a junior officially. thanks for the reply. I can delete my comment then. Also, your very first sentence is not true, as you don’t explain any of it. Thanks
I'm sorry, but this is possibly one of the most outdated videos I've ever seen about software development in my entire career. Class diagrams were a thing like in the... 90s? There are so many books explaining why hundreds of pages of documentation and UMLs are useless (or worse, counterproductive), and how "the code IS the design", and how the design evolves as soon as you put hands on the code because only writing code you get to know all the technical problems you have to solve... I also don't know a single developer in my network that benefit from UML in any project whatsoever. Some diagrams can be useful sometimes, for example a workflow diagram showing how a call is processed by different pieces of the application, just to make clear the chosen architecture, but those diagrams show modules, tiers, services, not just single classes, i.e. they show an entire new level of abstraction above the class one.
Thanks for the feedback One of the things that I try to do is present techniques and technologies that will be informative to layman and juniors I try to present it in story format This was one of my level 1 complexity videos I also do level 4 and 5 While I agree that this is FAR from new and that a single dev would not benefit much from this I do find that this is a current problem for example in the businesses that I worked at Nowhere did I say that hundreds of pages of doc or UML had to be published What I did say is that this would be a practical exercise in a team environment? Where planning should be done before coding As the code cannot be the design because the code hasn’t been written yet Not only that but I find that diagrams will give you a 10,000 foot view over the system when reading the code will give you a feet on the ground type of perspective, which is not always what you want Some people just cannot process the complexity of huge systems, especially as they are state of flux That being said, I absolutely love your feedback and hoped that we can go back-and-forth on several topics including the more complicated ones which I think will be better suited for your obvious level of expertise
actually there is a decent use for Class Diagrams: to design the initial concept/arch. Of cause they shouldn't be ever updated nor used after months in development
Hi! you haven't mentioned two very crucial things:
- you can't "plan" the thing you don't know. Business requirements are the exact example of such thing
- "change". Not actualized class diagrams are not useful (not to say are harmful). And modern IDEs make writing code MUCH faster then fixing diagrams. Just an example: renaming a method in ALL classes takes less then a second - finding and renaming it in diagram - takes hours.
Thanks for the feedback! I agree, class diagrams are just one tool in the toolbox, and adapting to evolving requirements is crucial. Those should have been in there. as for planning what you don't know - even after decades in the field I still don't know the best solution for this other than to have a flexible design.
Why does this sound like infomercial/sales video, rather then instructive one? Thank you for keeping it 4min
Good feedback thanks
I was actually going for a story approach that presents techniques or approaches to the general public or junior level devs
Let me review and see how to improve
@@theseriouscto yes, you could fit so much more into 4 minutes. I am
a layman, not even a junior officially. thanks for the reply. I can delete my comment then.
Also, your very first sentence is not true, as you don’t explain any of it. Thanks
The music conflicts with and overpowers the bad audio quality of your voice.
Thanks for the feedback
I'm sorry, but this is possibly one of the most outdated videos I've ever seen about software development in my entire career.
Class diagrams were a thing like in the... 90s?
There are so many books explaining why hundreds of pages of documentation and UMLs are useless (or worse, counterproductive), and how "the code IS the design", and how the design evolves as soon as you put hands on the code because only writing code you get to know all the technical problems you have to solve...
I also don't know a single developer in my network that benefit from UML in any project whatsoever.
Some diagrams can be useful sometimes, for example a workflow diagram showing how a call is processed by different pieces of the application, just to make clear the chosen architecture, but those diagrams show modules, tiers, services, not just single classes, i.e. they show an entire new level of abstraction above the class one.
Thanks for the feedback
One of the things that I try to do is present techniques and technologies that will be informative to layman and juniors
I try to present it in story format
This was one of my level 1 complexity videos
I also do level 4 and 5
While I agree that this is FAR from new and that a single dev would not benefit much from this I do find that this is a current problem for example in the businesses that I worked at
Nowhere did I say that hundreds of pages of doc or UML had to be published
What I did say is that this would be a practical exercise in a team environment? Where planning should be done before coding
As the code cannot be the design because the code hasn’t been written yet
Not only that but I find that diagrams will give you a 10,000 foot view over the system when reading the code will give you a feet on the ground type of perspective, which is not always what you want
Some people just cannot process the complexity of huge systems, especially as they are state of flux
That being said, I absolutely love your feedback and hoped that we can go back-and-forth on several topics including the more complicated ones which I think will be better suited for your obvious level of expertise
actually there is a decent use for Class Diagrams: to design the initial concept/arch. Of cause they shouldn't be ever updated nor used after months in development