108 How Do I Know If I Am Overusing a Principle?

How do I know when I am overdoing a given principle? Principles like SOLID, DRY, and TDD are useful, but can I overdo them? When is it too much of a good thing? These are the questions we are going to answer in today's episode of Dev Questions.

Website: https://www.DevForge.com/ 
Ask Your Question: https://suggestions.iamtimcorey.com/
Sign Up to Get More Great Developer Content in Your Inbox: https://signup.iamtimcorey.com/

Transcript

Copy Transcript Copied

SPEAKER_00 0:00

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_02 0:25

How do I know if I'm overusing a principle? There's lots of different principles in programming, but how do I know if I'm doing too much of one, like solid or dry? This is a question that was asked over on a suggestion site, and I thought it'd be a great one to tackle on today's episode of DevQuestions. Now, if you have a question, go to suggestions.iamtimcorey.com and ask your suggestion. Maybe you'll see it on a future episode. So let's talk about design principles, why we have them, and if we can overuse them or not. So principle is a big picture idea that we have learned can make software development better in some way. So it's this big overall concept that we've learned that we say, yes, that usually makes things better. And I do say usually, that kind of gives you a hint as to can we overuse it? So the answer to can we overuse it? Absolutely we can. We're gonna focus in on dry. Don't repeat yourself. Think about that principle for a minute. And then let's think through is there a time when we don't want to be dry? Is there a time when it's too much to try to not repeat ourselves? And maybe we should do some repetition. So, first of all, my first how do you know if it's too much is if you turn ideas and strategies into rules. So dry is not a rule, solid is not a set of rules. These are principles. They're named that way intentionally. They are things that we have learned make life better in most circumstances, but that doesn't mean that they're rules. And if you start looking at dry, for example, as a rule, then you will work yourself into bad situations. For example, let's just say you're gonna create two different console applications. One is going to say, hello world, thanks for visiting. And the other is gonna say, hello YouTube, thanks for visiting. Now, why is that two different applications and not one? It probably should be one. But let's just say there's two different applications that are similar, like that. And you say, wait a minute, I'm saying two console write lines in a row. Maybe I should create a class library that has a method where you pass in the two different messages, and then it prints out both of those, and I can reference it for both class libraries. So now you've added a new class library, a new DLL gets built, and a new DLL is maintained and upgraded and all the rest for one method, for one two lines of quote-unquote repetition. That's that's too much. That's going too far. That's doing too much work to try and save yourself what? One extra line? And really, was that even repetition? We could debate on that. But the the idea here is that we want to make sure that we are focused in on is it too much? Because the principle is designed to help make our applications better. Did it make our application better to have a separate class library that we're dependent on now that gives us one method that allows us to call two console right lines in one line instead of in two lines? Is that extra dependency and that extra build step process and the the fact that we're now use the same DLL in multiple places? So if we needed to put three in one and two only two in the other, that causes a problem. You see how it didn't really help us? It actually made our application worse. That's the problem we need to think through and address. So don't repeat yourself is great advice. And in fact, for about 95% of the time when you're a developer, you don't want to repeat yourself. But there are times when it's okay. And so, again, that first principle is if you turn ideas and strategies into rules, that's where you know you're probably going too far. Because dry is not a rule, it's it's an idea, it's a concept to help make our life better. It's not there to be a rule that we have to follow and get our wrists slapped if we don't. So, number two, is it going to make your application worse in some way? Because again, what's the purpose of a design principle? It's there to, it's, it's, it's an overall idea to make better applications. So the reason we have dry is because if we don't repeat ourselves, then let's just say we've written the same logic 10 times as compared to writing it in one method and calling that method 10 times. Well, if we find a bug in our concept of how we did that thing, if it's in the method, we just change it once. But if it's 10 times throughout your code, well, now you're changing it in 10 different places. You might miss one, or maybe even worse, you wrote the logic a little bit different somewhere in those 10 times. So having it once makes our applications better. But back to our example, that class library didn't make our applications better, it objectively made them worse. So if you just if you find yourself following these principles and it makes your application worse, you need to take a step back and say maybe we're overdoing the principles. So if it's harder to understand, if it's harder to maintain, or if it's more complex. And this is the one that's a little bit of a tricky one because you might say, well, Tim, if we look at solid, the the D stands for the dependency inversion principle, which we normally uh look at and carry out using a dependency injection system. And that can make things complex. We have to declare right up front in our application what all our dependencies are. And then we have to ask for dependencies from that central location. And so that can add some complexity to things, and it absolutely can. So if you're writing a console application, it's gonna write out three, 10, 15 lines of console write line, a few read lines. That's not really a place that you would want to do dependency injection. But when you have a large application, it absolutely is a place to do dependency injection because that's where it makes things simpler. When you go to a unit test, your dependencies are declared up front. So it's very easy to replace those with mock dependencies. And when you go to replace a logger with a different logger, you have to do it once, not a hundred different times in a hundred different places in your application. So, yes, that dependency injection needs to be thought through as to do I need this or not, because if it just makes your application more complex, then no, you don't need to use it. You need to think about not using it or using something different that's less complex. So complexity is something to think through. If it just makes your app more complex, then it's not worth it. You shouldn't do it. Okay, number three, if you use words like always or never, I always use solid. I always use the single responsibility principle, I always use dry. I always no, or I never do this. No. There's a reason why when you ask a senior developer, what do you want to do in this situation? They'll say it depends. If you ask me what's the best web framework to use, I'm gonna tell you it depends. And it doesn't just depend on a few things. There's a lot of circumstances you need to think through when figuring out if this is right for you or not. So always and never, that means you're probably overdoing these principles. And finally, when you can't identify the benefit. So you decide, yes, we're gonna do all of solid, but you can't figure out why it's helping you. Well, then you don't know enough to implement that principle. You need to think through and figure out why it's helping you. Otherwise, you need to take a step back and go, no, this isn't right for us. Okay? So those are the four ways you can know if you're overusing a principle. They also apply to a larger context of building applications, but they definitely apply to overuse of a principle. I hope that answers your question. Thanks for asking it. If you have a question, again, go to the suggestion.com and ask your question there. I'll hope to see it on a future episode of DevQuestions. Thanks for listening, and as always, I am Tim Corey.

SPEAKER_01 9:54

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 IamtimCorey.com and enroll in a course.