140. Is It Possible To Overuse DRY? Is Repeating Yourself Ever OK?

[@devfrederik7326]

Interesting, i had a similar problem at work, where my co-worker asked, if we should create a new service for a new functionality, or just put the functionality inside the existing service that is used same place as the new functionality. From my standpoint, it always depends, as you say. I figured that as long as the new functionality is close to the conceptual schema of the existing service and the new functionality is not introducing too many new concepts and is only used a few places, we should not overengineer until necessary. Then when the new functionality becomes too large inside the existing service, it can be split, and the existing service doesn't become too large.

[@johnnyserup5500]

The most effective approach in software development requires a careful balancing of the DRY (Don't Repeat Yourself) principle and Agile methodology. This approach emphasizes the importance of developing only the essential components while also considering the level of complexity involved. The ultimate objective is to achieve a harmonious integration of these two approaches, which will depend on the specific requirements of the project at hand. 🙂 - good video

[@IAmTimCorey]

Thanks!

[@whatgoglikeno6120]

The best way I ever heard DRY argued against goes like this "DRY is by definition always a trade off against coupling". One goes down, the other goes up. You have the exact same code in 3 places. You extract it into a method and call that method in 3 places. These 3 are now coupled, they all point to the same method after all. It's by definition NEVER free. For me coupling is a WAY worse problem than duplicated code. Duplicated code is so braindead to fix, IDEs can do it. Coupling is the annoying slowness you get when you try to implement something that should be simple, but its not because X Y and Z have to be taken into consideration and you have to wire this through here, but then you need to touch this and you cant becau...

[@IAmTimCorey]

Every decision is a balancing act.

[@jonathanmoore2139]

Very good message with perfect examples. The story of that package getting taken down is crazy

[@IAmTimCorey]

Thanks!

[@blackenedsprite8542]

Tim: dry or don't repeat yourself. Also Tim: now again, dry is don't repeat yourself Sorry, got a chuckle from that.

[@IAmTimCorey]

lol I’m glad.

[@wilso572]

Thank you for this video, I've been trying to convince my coworkers of this for years.

[@IAmTimCorey]

You are welcome.

[@marcocito9269]

When you break a software principle I think it is a good practice to leave a comment explaining why you did that. It deters other programmers to refactor something that appears wrong but is right in the specific circumstances.

[@IAmTimCorey]

That's a good idea.

[@LuciferTheBloody]

100%, overgenericising can be a major issue if DRY is blindly applied. Common pitfalls I see are Reflection, Dynamics/Objects and integer db columns that conceptually are used as a key to multiple tables instead of just having multiple actual foreign keys. Usually it is better having Type/Compiler/Structural safety than it is to reuse things.

[@ABMedia83]

Yep, sometimes it's just simpler to repeat yourself. You can't always throw everything into a method and or function. Sometimes you have to repeat yourself. Side Note: Yep, I will store my settings in multiple files depending on the project.

[@IAmTimCorey]

Thanks for sharing.

[@sarahhagen2051]

We overuse it where I work. We have shared libraries that have turned into a real pain to maintain. But, we also use SonarQube that enforces DRY. So, we’re forced to refactor even when we don’t want to.

[@josda1000]

Every tool has pros and cons. When everything is an absolute we become OCD like instead of getting the work done. The problem with calling dry a principle is that it becomes the first thing people want to fix.. but its really a design tool, IMO.

[@IAmTimCorey]

Yeah, making a principle a rule is a sure way to make bad code. Senior developers use the phrase "it depends" for a very good reason - it really does depend on the situation.

[@robdas1]

Very well explained. I think it comes down to favoring a pragmatic rather than dogmatic approach to coding.

[@IAmTimCorey]

Thanks!

[@techsamurai11]

Great video, Tim! Great video!😀

[@IAmTimCorey]

Thank you!

[@josda1000]

Get better Tim. And keep up the awesome work.

[@IAmTimCorey]

Thanks!

[@S3Kglitches]

No question is "always or never" except using foreign keys in a normal database schema :) My old colleague insists on not using them in production to be able to edit values manually in DB...

[@IAmTimCorey]

Ouch! That sounds painful.

[@mannetjie3704]

gosh! the point of fk constraints is data relationship integrity. only 2 reasons i can think of for removing them: when you don't care about data integrity, or for performance reasons (no checks = faster inserts, updates, deletes)

[@GBSCronoo]

I'm semi new to programming and I have this problem lol, have been treating it as a rule cause of all the ppl hammering it in so hard. Thank you!

[@IAmTimCorey]

You are welcome.

[@heman248]

Sometimes the function is so simple but because is reusing functions from different parts it takes you on a journey. The final function could be summarized into one line of code sometimes if it wasn't using external libraries.

[@IAmTimCorey]

Depending on the situation, it may also be helpful to not make it a one-liner in order to make debugging easier and to make understanding it easier.

[@albud6687]

There's joy in repetition There's joy in repetition There's joy in repetition

[@IAmTimCorey]

There is also pain.

[@AlekseyFilippovHuzzah]

Yes, it's OK. If DRY results in a bad abstraction, then it's better to stick with simpler solution, and, maybe, duplication.

[@IAmTimCorey]

Yep.

[@Norman_Fleming]

DRY but not dehydrated maybe a better way of thinking about it. If you are just rolling your own in the local application, then it becomes your problem, but that's your call as a developer. "You break it you buy it!" One problem with not keeping dry. People 'borrow' code, because they just need one tricky method. They do this a few times in a few small applications. Now you have 5 copies of code that is actually hiding a bug. Now you have to track down all copies of the bug/vuln/leak. If you DO borrow code, you should at least put comments in both places so you can back-track later when issues are discovered.

[@IAmTimCorey]

That's also where DRY is most applicable - if you are using it multiple places, you should probably make it a method or otherwise stop the repetition. It is tough when different people just use it once, though.

[@analyth]

Love the comparison with groceries 😀

[@IAmTimCorey]

Thanks!

[@runtimmytimer]

The project I’m on is a hodgepodge of contractors. I’m the only one who wants different models. So we have one model database up to API. Yep, database models have JDON name attributes on them. Drives me nuts.

[@IAmTimCorey]

Ouch.

[@hamzamohamed6748]

Unrealated question but does the web development course come with a year of coding ? It helped me tremendously with the c# master course.

[@IAmTimCorey]

No, but you could add that as a suggestion for a future update.

[@niksatan]

I think for is repeating yourself ever is ok is that repeating yourself is ok

[@IAmTimCorey]

There is definitely a place for repetition, as I've said before.

[@RioTheHitman]

Tim do you have any tips on increasing memory in the development space? Some developers have photographic memory but unfortunately I do not. For example I always struggle with remembering large libraries after I haven't used them in some time.

[@IAmTimCorey]

That's a good Dev Questions suggestion. Please add it to the list on the suggestion site so others can vote on it as well: suggestions.iamtimcorey.com/

[@nwdreamer]

Wait Tim... Didn't you do this topic before??? 🤔 😜

[@IAmTimCorey]

I've covered it quite a few times. 😆

[@Patriqu]

I think, more important over DRY is YAGNI (you ain't gonna need it) and KISS (Keep it Simple, Stupid). 🙂

[@IAmTimCorey]

But like with DRY, you can overuse those as well.

[@dasfahrer8187]

In regards to generics, DRY and other refactoring guidelines, I've moved to doing all of that at the very end once the application is complete and stable. I've had too many times where I got too clever too early on and it lead to more development time because outlier cases threw a monkey wrench into the development process and I had to backtrack.

[@IAmTimCorey]

Yeah, premature optimization can be a problem. Just be careful not to wait on obvious optimizations or skip the step of optimization at the end of the project.

[@dasfahrer8187]

@@IAmTimCorey Even with seemingly obvious optimizations I've ran into problems depending on how complex the project is (or the customer's changing/forgetful needs). There have been several instances where we even talked thru and planned out a project only to find that once we got in there that something we thought was concrete needed to change. It's usually only the simplest of projects where early optimizations have held strong. Doing it at the end is a bit of a drag, but it has paid off big time so far for us. Maybe we just suck at planning though still. 🤣

[@0i0l0o]

peachy

[@IAmTimCorey]

👍

[@jobrench2563]

Someone knows something about the event logs on windows. My employer gave me some restrictions. I can't work weekend. However, I have some mental problems and can't write code some days so I need your help about event logs from windows. Can I cheat the timer from network or these logs use the local time on my machine? In will test on my pc before, but I don't know for system from federal. I am able to write protocols and can make everything you want in tcp/ip. I am really good with protocols, much better than a cyber operator from federal. I need something easy, I can build a pcb but this is only for 2 days. Is these events with local timer or network? I can't do nothing except coding in my life. Do you know where they can spy software developers on a laptop?