Today on the show we are joined by the one and only Steven Solomon! We are going to talk about The DRY Principle and how and when it can be useful. Steven helps us unpack the types of situation that require drying out, when things get too dried out and what constitutes necessary action in this regard. Steven makes a good case for leaning on product managers and when to do this, as well as explaining the worst case scenarios in which you might find yourself. We also ruminate on the ways that The DRY Principle fits among other comparable approaches. Steven believes that it is just one of many paths to a similar solution. We all share a bit of our good and bad experiences with drying code and we also hear from Steven about an exciting upcoming talk he will be conducting, so make sure to check that out!
Key Points From This Episode:
Transcript for Episode 113.The DRY Principal is Misunderstood with Steven Solomon
[0:00:01.9] MN: Hello, welcome to The Rabbit Hole, the definitive developers podcast and fantabulous Chelsea, Manhattan. I'm your host Michael Nunez, our cohost today —
[0:00:11.2] DA: Dave Anderson.
[0:00:13.6] MN: And today we're talking about how the dry principle is misunderstood.
[0:00:16.1] DA: Yeah, I'm, I'm sure I'm getting it wrong, but luckily we have a special guest here who's anything but dry to help us through it.
[0:00:22.8] MN: Today we have Steven Solomon. How's it going, Steven?
[0:00:25.7] SS: It's really good. Thank you for having me on.
[0:00:16.1] DA: Steven, tell us a little bit about yourself.
[0:00:29.4] SS: Yeah. I had been a programmer since 2007 I've been very lucky. I got to work on a large variation of different types of projects. I've worked in compiled languages and really recently I've gotten a lot into a Ruby and Rails and I'm beginning to play with Elixir. So I've seen that this kind of wide swath of different programming languages as well as different industries.
[0:00:54.3] DA: And it doesn't matter which one was your using, everybody's trying to dry things out. It's got to be dry.
[0:00:16.1] MN: For are listeners who may not know what is dry? D-R-Y.
[0:00:29.4] SS: The DRY Principle is as something that was first written about by Dave Thomas and Andy Hunt in their book A Pragmatic Programmer. Yeah, there's actually a new version coming out so people should check that out.
So in that, in that book they define The DRY Principle as every idea should have a single unambiguous authoritative representation in a system. It's a bit wordy.
[0:00:29.4] SS: but basically, you know, if you look at code and you'll see, you know, two functions that have the same line of code, then you should just extract that into a method. Right?
[0:01:37.4] SS: That's often what we talk about in our industry, but their definition really seems to imply that it's about not duplicating ideas.
[0:01:47.9] DA: Right. That's very interesting. A bigger concept maybe.
[0:01:50.3] MN: Because it's like you often see DRY and people spell it out where it's like don't repeat yourself. And people will believe that don't repeat the functions or the methods that you're doing. But as you mentioned it is not just methods, but the idea that is that is encapsulated by the methods. Don't repeat those things.
[0:02:07.8] DA: I feel like when you, when you hear about the try principle, you're like, "Oh, I get it and this is so powerful. Like I only have to write it once." And then you just refactor everything into a function somewhere. You're trying to trace through your code. You're like, "Oh God, what have I done?"
[0:02:24.6] MN: Yeah. I mean I may, Ruby might be a little bit difficult. I know I use [inaudible] way for Java and you could just like command click your way back to the beginning of time to find at the beginning of that function. That gets repeated often.
[0:02:38.3] DA: Right. Especially when you find those refactoring tool's. I've been using [inaudible] and man, just extracting all those methods feels pretty good.
[0:02:49.2] SS: I cannot program without a JetBrains product. I also I don't work for JetBrains.
[0:02:53.7] DA: Yeah. They're not paying us either. Conrad, really a friend of the show Conrad Benham, really sold me on it for a long time and now I get it. I get it.
[0:03:03.1] MN: Yeah. So like the idea, we often hear about The DRY Principle and we as experienced engineers, we often talk to and talk to junior engineers about a how you shouldn't repeat yourself. So that's something that like gets passed on as knowledge, but people often just see it as just like methods. So is there like a mindset that you care to elaborate, to separate it from just methods and on to ideas?
[0:03:30.8] SS: Yeah. So to kind of paint the problem a little bit more, a lot of what I've seen on projects I'd been working on have been this scenario where people would extract things way too early and eventually requirements require those two things to be different. And all of a sudden there's this nested conditionals are case statements or even, or even multiple different random objects or functions that are all injected in the same moment. So it becomes this really tangled mass that becomes like untraceable.
[0:04:07.6] DA: Right. And like as you're probably not the person who extracted that method to begin with, you're like, "Okay, well that person was smarter than me and they had a reason for doing it. So I must just need to take this other level of abstraction and just jam it in here. Just put, put another if statement, you know, which I think we talked about it a little bit with Jacob O'Donnell.
[0:04:27.4] MN: Yeah. Uh, that was the episode, Death by a Thousand Ifs. so if you have the idea, you had this idea of this class I think you mentioned before in time, like the God class that just constantly is in control of everything and you don't know the context in which the individual whole created this class with all these variations and what not. So you are leaving it up to the developer to have also had some context and those changes. But then ultimately it may have been too dry, I guess like it was dried way too early than it should have been.
[0:04:27.4] SS: Yeah. They're oftentimes like, and I've made this mistake is just responding to seem duplicate code and thinking that's as far as the principal goes and then getting into trouble and then now you have to find a way to extract out these separate things because you know you're in an application where your pricing, grocery items and meats have a different set of business logic than produce does. And as long as those things are both dependent on a shared thing, you're never going to be able to do it easily. Right. I mean you could hack it in there, but you're going to be worse off.
[0:05:44.4] DA: Right, yeah. When those FDA requirements come in, really going to be in a tough place.
[0:05:48.9] MN: But then before jumping in and like thinking about drying up everything, when, when do you look at a piece of code and decide whether it needs to be dried up?
[0:06:00.2] SS: So the number one thing that I try to do is I try to advocate on my team to go to a product person or a subject matter expert. And they're usually someone who's been in the industry for a number of years, whenever they are. If, if you're in groceries, there's like the grocery expert and he's been there for like 20 plus years or if you're in finance, there's someone who's been there for 12 or 15.
And they are the person who has a gut instinct and experience too, to be able to tell when things should change at the same time and what things are truly related. And I think that's the best advice I think you can do is just find who that person is and draw out the business objects, not the like layers of your architecture and presentation and not design patterns through, yeah.
Leave those things on the out of it. But like conceptually, like what are the moving parts that facilitates that functionality? And they'll react and they'll be like, what is that? Yeah. And um, I was actually talking to us a stakeholder a few years ago and she had this wonderful, wonderful reaction and it was, "Do you even know how this is supposed to work?"
[0:07:20.1] DA: Like programming?
[0:07:21.3] SS: Or like the system. So like describing her, her business domain and you know, sketching out on the whiteboard, just in complete shock at like what was, what the mechanism inside the code was to facilitate that. Like the concepts were not recognizable to this person who was an expert.
[0:07:41] MN: Right. Sure. Yeah. There's a lot those conversations like or rather there's books like Domain Driven Design that talks about how your coach or reflect the real life situation or or that in which the expert would be able to understand even like the diagrams and whatnot. And I think your comment about going up to the PM to ask questions is a great point because we often see like a feature story and then we're really quick to just run and program cause like those that we love to do.
Then we get caught up in like design patterns and stuff like that and try to make it look like elegant code when in reality it should reflect real life. And I think the expert is the person that would bring you down to let you know what real life looks like and how we should implement that in the current or there.
[0:08:30.7] DA: There should be like some kind of an overlap really between like nice and good code and elegant code and, and this domain of focused concept.
[0:08:41.5] SS: Yeah, there are definitely moments when did domain could be tightened up because you know, oftentimes when they're automating something, it's never been run before. So oftentimes it hasn't run before. So it hasn't had be that accurate. It's kind of like, it could be conversationally accurate, but, but not, not accurate enough to, to run with, you know, Boolean logic and where it can be fuzzier.
So that's really —
[0:09:11.1] DA: And the detail on the specification you got to go to get there.
[0:09:14.3] SS: Exactly. And that's really the starting point. That's the number one thing I think a team should be doing. But then there's, there's a few other techniques. If you can't find that person or that person doesn't exist. Like if you're in a startup,
[0:09:26.7] MN: right. I mean, I was gonna say, I was gonna say you mentioned a a food expert and I, I like to think that I am a food — I've been eating for the past 31 years and know my way around a supermarket. But suppose if you can't find, you don't have a PM as you mentioned, you could be working at a startup or this is, you know, you yourself are building a product that home with the, you know, pet project that has got a lot bigger than a pet.
What are you doing when you are, when you don't have the resources to ask an expert about something?
[0:09:59.5] SS: So when I do in that context is I ask myself two questions and I didn't come up with these questions. Kent Beck did. Seems to come up with a lot of wisdom in our industry.
[0:10:07.1] MN: Yes.
[0:10:08.3] DA: Some good tweets there.
[0:10:10.6] SS: Oh yeah. So he wrote this blog post called 'Bits Vs Clumps Vs Just Right'. And he lays out these two questions. The first one is, can you reason about two ideas separately. So, going back to that grocery store example, you know, looking at my backlog and looking at my context, I can say, "Well, here's this disease changes coming up for produce and those produce changes are not supposed to affect meat. There's like no stories in my backlog to affect me."
So it's like I can, I can reason about these two things separately. It's clear that these things are about to have to change for totally different reasons. And then he, he tells you to ask a second question and that puts it in a two by two format, like a grid, a row and a column.
[0:10:57.2] MN: Okay. Everything is in a two by two column. What it's like, uh, the squares in four places. So what's the other question?
[0:11:03.2] SS: the other question is, are those things actually separate in the code? And then from there you can really decide what you need to do.
[0:11:14.9] DA: I see, so kind of thinking about like where the business value was clumped versus where the actual implementation is kind of organized.
[0:11:22.6] SS: Yeah. So like an implementation that's tied together, but it's going to change for separate reasons is going to be very painful to change. And oftentimes if you have any kind of successful system, it's going to be big, hairy and complex. So there's going to be a lot of threads to try and pull those ideas at part.
[0:10:42.2] DA: So what, what's an example of something like that? Like where do we live in all of these quadrants were like let's take me on a tour of the good and the bad and the ugly.
[0:11:51.7] SS: So you want me to go through like the two by two and like which —
[0:11:57.2] DA: yeah, I'm trying to visualize it. Like what's, what's some examples that we could like a concrete this with a little bit? So I guess like if you have your business value and your, and your code concentrated, like if you're saying yes to both of those question, then that sounds like you're in a good spot.
[0:12:20.6] SS: Yeah. You don't do anything.
[0:12:22.6] DA: So you have, you have your, you know, vegetable objects in your meat object and they're just separate and they all do the things they need to do and you're, you're and a happy place.
[0:12:31.9] SS: Yeah. So that's a pretty good scenario. Another scenario is your vegetables and meat object art are kind of tied together, but the business value is separate. And that's a scenario where you need to separate things, you need to make sure those, those model reality.
[0:12:47.2] DA: So like in that case, if there was a new requirement for me, like you know, the FDA changed their regulation and you can only have mute on the shelves for two days or something, then you'd have to change vegetable code too and that would feel a little bit bad.
[0:12:59.1] SS: or worse if there's any kind of, um, government restrictions around vegetables. Now you have to balance like, how do I fend off the meat, right? Government restrictions so that it's okay.
[0:13:12.8] DA: All those tariffs on the Mexican tomatoes.
[0:13:15.8] MN: and Avocados, oh no, no.
[0:13:18.2] SS: Countries going to shut down.
[0:13:23.2] MN: So keeping in mind of all these different complexities between these two objects, we would sit down and then kind of wonder do we want to build these two, these two objects and rather than just like drying up all the time like, "Oh yeah they'll have government restrictions, soul just dry that up." But then the government restrictions would be different depending on whether you're vegetable or meat for example.
[0:13:47.9] SS: Yeah. Letting the domain be the thing that drives whether or not something is actual duplication and not the code happening to look similar. If that makes sense.
[0:14:00.1] DA: Yeah. Yeah, definitely. Cause I guess you would also like fall into another quadrant where like, you know, everything's all clumped together but that's fine because like those things need to change together. Like vegetables and meat for some reason are exactly the same way. We don't worry about it or like the way that our business cares about Vishal and the meat like doesn't have any relevance.
[0:14:19.5] SS: Yeah. There's one other scenario we didn't really talk about in that space that Kent lines up and says is like the worst scenario you can find yourself in.
[0:14:24.8] MN: We need to to talk about that one. Go ahead.
[0:14:31.6] SS: Yeah. So the worst one in his mind was you have an idea and it's spread about the system. So like if my logic for calculating meets, there's no way to change that in one place and I have to like change it all over the place and it's this tangled web and it's just kind of there.
[0:14:49.7] DA: Oh no. Just sprinkled all over the place.
[0:14:52.6] MN: I got to pull out the shotgun in that. Go around the whole code base to make this change. Change their, boom regulations here.
[0:15:05.8] DA: Added, you know, 20 lines of code changed 15 files.
[0:15:12.1] SS: Yeah. And it, it's really easy to do, especially with finding replace. Oh my gosh. Like if you know what you're searching for and you're good enough. At generating some reg X. You know, I've seen some crazy stuff get replaced.
[0:15:31.6] DA: I feel like my weakness at reg X read. Jack's is actually like, you know a benefit sometimes cause I'm like, nope, too lazy. Not going to do it.
[0:15:34.9] MN: Change all the things.
[0:15:37.6] DA: Nah, I'm good.
[0:15:36.6] MN: Yeah or [inaudible]. I mean we're not paid by idea, but the [inaudible] does a really good job at find the replace and depending on the language you're using.
[0:15:45.8] DA: so that if they wanted to pay us, we can do a fake advertisement.
[0:15:50.2] SS: They just made it even worse because now they have this thing called structural replace. So you can define like the attributes of like a set of Java structures and be like, "I want you to take that structure and map it into this structure." And it'slike, yeah, so that exists.
[0:16:07.4] MN: Oh man, that goes shotgun surgery tomorrow at the client. It's going down.
[0:16:13.9] DA: So much power. Too much power.
[0:16:17.9] MN: So the idea of dry isn't just as we discussed, just functions that were, we're trying not to duplicate. So we have to ensure that when we are given new feature that there is some of the thought behind designing it and not going stir crazy and making it as dry as possible.
[0:16:42.9] DA: Do we have any personal experiences about like how you've tried to apply a DRY?
[0:16:43.8] MN: I mean I often find myself like drying up methods and functions, but I try not to do it. There are oftentimes where repeating yourself just kind of make sense because it's just easier to read the code. This is something, uh, me and Dave spoke about earlier in life when we were talking about refactoring and I think like the idea that that you could go into this refactoring craze and dry everything up can often lead to more confusion and being able to read, read a piece of code that is duplicated twice.
I think like if the limit is over two, then you're like, "Okay, this could read better if I just gave it a better name and then I took all the functionality and put it in the method."
But yeah, that's my limit. If it's more than two, then I do a full blown dryness in that regard.
[0:17:35.5] DA: Yeah. I mean I remember like kind of getting addicted to dryness for whatever reason, like using R Stack, especially with like a, you know, wet blocks and all that. That was like kind of a new thing to me and I'm like, "Oh, everything can be dry. Everything can be like this whole like crazy chain of things that get like spun up by your test fixtures."
[0:15:36.6] SS: The shared examples or you know it, you can abstract your tests.
[0:18:03.3] DA: Yeah. Right. Yeah, yeah, exactly. Like, and you know, everything's just acting on subject and as one line long and it's like, "Oh my God, I'm like so good at this." And then someone else looks at it and it's like, "Oh wait, I don't understand this. I was like, oh, maybe it shouldn't be this dry."
[0:18:22.3] SS: So the whole thing here is, is the dry principle was developed to like combat this smell of shotgun surgery. I don't recall if Dave Thomas and Andy Hunt laid it out as that, but it's really what they're trying to fight, that there's, there's something else and see other end of the spectrum. It's divergent change and I often don't hear people talking about that as it applies to their code bases.
[0:18:44.9] DA: What does that concept mean?
[0:18:46.2] SS: Divergent change is another code smell that's laid out in Martin Fowler's book Refactoring a, this one is all about changing the same place in your system over and over again for different reasons. So it's the kind of this super, that God class, if you will, that's everyone goes in and no matter what the new feature is, you got to change this spot and tweak this logic and add a new case statement.
[0:19:12.7] DA: All right. Yeah. That's like the, the violation of the open close principal and solid, right where you're like, you have to, it's not closed for modification.
[0:19:21.1] SS: Exactly.
[0:19:23.3] DA: You got to go in and you, you get the shotgun out and you, you modify it. I feel like we should have, we should have the show where we go through a solid principles sometimes, some of them are like fiddly bits, like I kind of a refresher on that. But you know, it's interesting how these kind of all tie together and you know, these things that your code is kind of telling you when you're like pulling it apart and trying to put some new features into it, you just have to listen to it and know what the right path is to go down to fix it.
[0:19:51.3] SS: Yeah. A lot of these, these concepts overlap. I kind of think of it as there's these different people and they all have different ways. They look at these things, but they're all hinting at the same problems, like single responsibility principle and Kent Beck's four a simple rules of design and the DRY Principle and Solid and all these things are just kind of layered on top of each other as different ways to slice the same problem.
[0:20:21.4] DA: Right. Yeah, yeah, yeah. Different ways. It's important to have that language though, so you can kind of like point at the nuance of like what is specifically the indication of what, what's wacky in this particular case. They're nice tool to have in your toolbox.
[0:20:33.9] SS: Yeah, definitely.
[0:20:35.2] MN: Steve, how can people contact you?
[0:20:437.4] SS: They can reach out to me on Twitter at ssolo112, that's s-s-o-l-o-1-1-2.
[0:20:46.2] MN: Awesome. And you have a talk comung up, right?
[0:20:49.5] SS: Yeah, I'm speaking at NYC RB about the same concept. The DRY Principle being misunderstood and that's on June 11th.
[0:20:56.2] MN: At 7:30 PM?
[0:20:58.1] SS: 6:30 PM.
[0:20:59.8] MN: 6:30 PM so if you're listening to this episode, that means it is today.
[0:21:03.9] DA: Oh my God. Get up there.
[0:21:05.2] MN: Yeah, you got to go for show support. Show some love. Steven Solomon. Thanks a lot man.
[0:21:11.6] SS: Thank you.
[END OF EPISODE]
[0:21:12.9] MN: Follow us now on Twitter @radiofreerabbit so we can keep the conversation going. Like what you hear? Give us a five star review and help developers just like you find their way into The Rabbit Hole and never miss an episode. Subscribe now however you listen to your favorite podcast.
On behalf of our producer extraordinaire, William Jeffries and my amazing co-host, Dave Anderson and me, your host, Michael Nunez, thanks for listening to The Rabbit Hole.
[END]
Links and Resources:
