I am Tim Corey. I teach coding online and my inbox is full of questions from current and future developers. I wish I could sit down with each of you and share the answers I know will help you go further, faster in the world of development. This podcast is the next best thing. On this podcast, I will answer the biggest questions people are asking! Send us to your suggestion for a future Dev Questions at https://suggestions.iamtimcorey.com/ To keep the podcast coming, like, subscribe, rate, and share it with your friends and colleagues. See why thousands of students have chosen to learn to think and code like a professional developer at www.DevForge.com.
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
0:00
|
9:45
Are UML diagrams important? Do UML diagrams help developers create better applications? Do we need to know UML to get a job? Can you use UML with Agile? These are the questions we will tackle in this episode of Dev Questions.
Welcome to the Dev Questions Podcast with Tim Corey. Join us each episode as we tackle the questions you are asking about a career in software development, understanding the industry, and new technology. If you're just starting out or you want to grow stronger as a developer, this is the place to get your questions answered. Now, here's your host, expert developer and online educator, Tim Corey.
SPEAKER_01
Are UML diagrams important for C sharp developers? This is a question asked by Torio Zan. Sorry, I butchered that name, I'm sure of it. But it's an important question because it gets asked a lot, and I might have a different answer than you expect. So, UML diagrams, if you're not familiar, are a way of modeling the design of an application. Usually it's we're talking about designs at the class level, where you say this class does this and it interact interlinks with this class, and you kind of model out how the application is going to be designed. It's very common to see UML diagrams in a university setting. This is a pretty uh common way to teach programming and the programming logic is to do in in UML diagrams. But when it comes to real-world use in general, I would say no, UML diagrams are not important for C sharp developers. Now, that may panic you or it may relieve you, but let me be more specific. I said generally, there are times when UML diagrams can be important or can be helpful. So let's talk about the places they can be useful. And the first one is big picture. When you want to communicate how your application will work or interact with other applications, or maybe you're developing a microservice ecosystem. That's a great place for a UML diagram because it allows you to see at a very high level how things interact with each other. That gives that big picture without having to be super complex. It can show how systems work or how systems interact. And it also can show the flow of an application. If you have a microservice environment, there is a flow to it where let's just say you have an ordering system. And so a person comes to the website and they fill out a form and say, I want to buy this bike. And so you put it in a cart and they fill a form out and they submit it. Well, that may trigger a microservice to send an email. It may trigger another microservice to start talking to the warehouse to get that bike put into shipping. And it may trigger a few more down the road. Well, to be able to see that flow in a UML diagram can be helpful. So those are the areas I see UML being useful. But let's talk about where I see UML abused or not useful. And that is defining code. If you have to define your code first in UML and then take that UML and turn it into C sharp code, that's way too granular and you're doing way too much work. I think. Again, personal opinion. You can disagree. That's fine. Let me know. Let me know how you find it valuable. But what I've seen is it takes a lot of time. And often it's used as a planning device to say, oh, we're gonna plan our app, our application, we develop it in UML, and then we can very quickly convert it over a C sharp code. And so the argument is, well, we can very quickly move from our UML to our COO, but how long it takes you to do the UML? And this is where I highly recommend you use pencil and paper or a whiteboard to develop your application. If you went through the C sharp application from start to finish course, um, it's on YouTube as well as my my um I amtimcorey.com. I walk through the the wood framework, W-O-U-L-D. And I walk through my planning process for how to build an application. And whether you're doing agile scrum or whether you're doing um waterfall or a mixture of both, or whatever you're doing, you can use the wood framework as a kind of a principle for how to design an application. And one of the things it talks about is doing your planning on paper. And the reason why is because it's very easy to cross something out or erase something and redraw it. I love my whiteboard because the same thing, I can erase something and start over. And I'm not worrying about the tool, I'm not worrying about the right shape, I'm not worrying about, oh, that didn't quite link up right, and I'm fiddling with things. That's the biggest problem I have with UML is that you're fiddling with things all the time. You spend so much time on the tool and getting the right shapes in place and getting the right lines drawn in the right spot and make sure they don't overlap and make sure you got it all figured out that you miss the fact that you're building an application. That's for me a problem. That's why I don't use any tool, any digital tool for designing my applications. Not at first. I use everything on paper or whiteboard because it's very, very quick and I don't have to worry about the tool getting in the way of me doing my job. I don't have to split my my brain time between thinking about the tool and thinking about the code. I'm only thinking about the code. So I really, really don't like UML for designing applications. Or for really for anything detail-oriented. If it's a detail, it shouldn't be in UML. That's my opinion. Uml should be for big picture stuff to show the overall idea to help you conceptualize in your head the overall picture of your application or your series of applications, sure. But to design your actual code or even the structure of your code in UML, I think it's way too granular. I think it wastes too much time, and it's in the end not useful. Now let's talk about where I've seen this in production. Um, I spent six years of my early career as a consultant working with multiple companies, um, large Fortune 500 companies and international companies and local companies on all different sizes, um, working with our coders. And then I spent years in education, and then I spent more time back in software development and then back into consulting. And I've consulted for a lot of different companies over a number of years, and I think I might have seen UML once in all those that time in all those different companies, and it wasn't really that useful. So it's not like I'm saying don't use UML, but everyone in business does. I have not seen this as being a really big impactful thing in business. It may be anecdotal to my situation, but again, I've worked with hundreds of companies and haven't seen this in use in any significant way, especially not for details. Big picture, sure, I've seen UML use for that, but not for detail. So that's my thought. It may be different in your area. You may find that companies really focus hard on that in your area. Um, some European companies sometimes do, or at least seem to, but in my estimation, it seems like it more often than not, it's the university that does it rather than the actual companies. And the reason why is because it's easier to recognize a shape rather than code. And so it's easier to test based upon those shapes versus based upon code. That's why I think universities are about theory, they're not about practicality in most cases. So that's my opinion. I love to hear your thoughts on it. Thanks for asking this question. Um, if you like your question answered in this series, either use the podcast page at imtimcorey.com or leave a comment on the YouTube video. As always, I really appreciate when you share this video. Thanks for listening, and as always, I am Tim Corey.
SPEAKER_00
Thank you for joining us for this episode of Dev Questions. Tim is committed to making it easier for you to become a developer. If you would like to help make more content like this possible, please like, subscribe, rate, and share Dev Questions. You can also send your questions to questions at IamTimcore.com. Until next time, remember, you are too smart and your time too valuable to waste it making all the mistakes Tim did. When you're ready to learn to think and code like a professional developer, head over to IamtimCore.com and enroll in a course.