DRY Is Bad!

DRY is the first programming principle we learn and probably also the first we teach to newer developers. However, DRY has become something like a dogma that is applied blindly. And, unfortunately, there are a lot of scenarios where applying DRI is Bad! In this video we'll look over the good parts of DRY, but we'll also thry to understand the circumstances when DRY is Bad. We practical code samples.

Join this channel to get source code access and other perks:

Mentioned books:

Also follow me here (especially if you are a self taught developer):

Content:
1. Intro: 00:00
2. Software, art and dogma: 00:30
3. DRY - the good part: 00:54
4. DRY - the origins: 04:01
5. DRY gone wrong: 05:02
6. Wrong abstraction: 08:21
7. Uncle Bob to the rescue! 10:48
8. That's All, Folks! 11:55

My setup:

[siposz]

I absolutely agree, that applying DRY principle could add unnecessary complexity to the code, but.

public void SendMail(string body, string subject)
{
...
}

would be the natural signature of the function, which in this case solve all the problem you mentioned.

[moeelhariri]

I’ve been a fan of your content for a while now; it’s definitely refreshing and insightful. You do such a great job of explaining the why and putting things into their proper context. Thank your for the quality videos and keep them coming!

[simplepycodes]

I really like how you are using principles and "best practices" in a mindful and practical way, and not following them blindly. Thanks a lot, very useful content.

[dczoekj]

I never though I'd seen such thing, but I guess it happened somewhere, this is also a common problem in UI development where the code is so "DRY" that there are 1000 booleans to determine what to show. DRY however helped me reduce bugs to 0 once fixed on one place, I remember a project where each class had the same flow over and over again, and developers sometimes forgot when to call what and how, so bugs were created. Making your code as a framework, that is, if you want an email there is only 1 way to do it through the small one method class, is a sure way to create real reusable cross-project code without any bugs. But generally it's good to point out when explaining to people that DRY is about code, not data, data is a variable, and code is not, how we send email is the code, what is inside the email is the data.

[vaeluck]

Thanks for taking your time to do this video. Very insightful!

[harag]

Good video, however I'd have to disagree with your 2nd example. If designed from the start, then you would just need one extra parameter, e.g. an Enum specifying the "type" of email, "NewOrder", "NewCustomer", "InvoiceOrder" etc. the DRY part of the code, would be the setup of the HttpClient, pulling the emails etc. the bit you would need to change is where the ENUM is used to maybe pull the email text/subject from a databased based on the type and to populate {0}, {1} fields with in the text. This no matter how large your code gets, you simply add a new enum entry, and add the text to a database table, and voila, done - no other code changes.

[TheDavidManea]

Delightful content as always! Love it!
You're one of the best teachers anyone can ask for!
Keep up the good work!

[T___Brown]

Lol i have an email fluent builder but thats because we need shared parsers for different inputs and ability to send to a queued email system. I would add that DRY can also severely complicate microservices

[riddickful]

I like the way you look at things and maybe would like to see some more advanced release-quality ccode, what do you think?

[calinmarian]

Nice examples, had the same feeling with some code duplication, applying DRY made it more complicated

[TheRicherthanyouguy]

First off I’m enjoying the content for sure please keep up the good way. I deeply enjoy the challenges to dogma. I will add potentially a counter point to the example in that when I looked at I believed that the email service may have been viable if an email object was passed into the method but built by the caller. Now while saying that I will be honest I have also seen code like this and I have legitimately ignored refactoring it because it was an application of massive size and I just couldn’t convince myself to increase the complexity a single ounce more. In short I think the code in the example could have been made to work but I 100% agree we can’t simply refactor code to respect dogma if the code has began to suffer due to dogma.

[Vreth]

Couldn't agree more - being dogmatic about these things leads to unmaintainable code, I've seen it over and over again. Great video 👍🏻

[romanmotyka]

I don't agree. Normally it is rare situation that we just send text in the email. Probably we need some kind of template to be generated. What if we also want to send sms not only email? I would rather make a "notification service" for that.

[Eamo-]

Key point @ 11:30 . Great video and worth watching the whole thing

[Stettafire]

As with evetything in ptpgramming. "It depends!"

[majormartintibor]

Very good video, couldn't agree more.

[DanWalshTV]

While I understand the points being conveyed in the video (and mostly agree), I think this has less to do with DRY as a core principle and more to do with poor design implementations and being dogmatic. Any principle could be perceived as "bad" when implemented poorly or verbosely. As a whole, DRY is *generally* a good rule of thumb to stick by, within reason. However, being practical should always come first. Another core principle people seem to forget, especially later in their careers, is KISS.

In that regard, the title is a bit click-baity and seems to be unfairly putting DRY in the crosshairs when that's not the core issue. It should be less "DRY is BAD" and more "Programmers need to stop being dogmatic" as this applies to MUCH more than DRY.

[dandayne]

The fact that you can implement DRY badly does not mean that it's bad. The example you showed is indeed terrible implementation and I've also seen such code in production, but applying dry is never bad if implemented correctly. Bad code is bad regardless of dogma it's trying to follow.