Why do so many developers get DRY wrong?
Dan Abramov’s excellent Goodbye, Clean Code post (wherein he learned it was wise to walk back an overzealous refactoring) reminded me of something Dave Thomas said when we interviewed him and Andy Hunt about the Pragmatic Programmer’s 20th edition:
We’ve also looked at the reaction to various parts of the book, and discovered that we weren’t really communicating as well as we thought we were some of the ideas that we had. A classic one is DRY. DRY has come to mean “Don’t cut and paste”, but the original “Don’t repeat yourself” was nothing to do with code, it was to do with knowledge. So we’ve had to go through and update that… [🎧]
Young Dan’s misguided refactoring began the same way so many of ours do. With these four little words:
But it was repetitive.
I’m not picking on Dan here, by any means. I’ve fallen into this trap countless times in my career and I even heard Feross talking about the same thing on a recent JS Party episode about refactoring.
This got me thinking: why do we so often get DRY wrong? I have a few thoughts on the subject…
Names really matter
One of the reasons why DRY is a thing that most of us think about is it’s so easy to remember! It’s a great acronym. Except.
“Don’t Repeat Yourself” as a name is, itself, a leaky abstraction.
Lets refer back to what Dave Thomas said above:
the original “Don’t repeat yourself” was nothing to do with code, it was to do with knowledge
The trouble with DRY is it has no reference to the knowledge bit, which is arguably the most important part! I can’t blame the guys for going with DRY, though. DRK just doesn’t have the same ring to it…
We’re good at pattern matching
Humans are pattern matchers. Developers, especially so.
The more code you write (and read), the more patterns just pop out of your editor and stare you in the face.
I don’t know about you, but I appreciate patterns so much that I want to pull them out, give them a name, (the best ones even get their own file), and refer to them.
Lowest common refactoring
Another reason why we’re so eager to DRY up our code is that it feels so good to do it.
Think back to your early days of programming. You likely copy/pasted code from one area of your program to another. You did this out of necessity, because subroutines/functions/etc just weren’t a tool you knew how to wield yet.
Once you eeked out enough XP to reach Level 2, condensing that copy pasta down felt amazing. Suddenly your code looked more impressive. Efficient! Clean! Simple! This is like the lowest common form of refactoring. But it feels good…
Those are a few of my thoughts on the matter. And to be clear, I’m not pro code duplication. I’m a Rule of Three person. I just find it interesting that one of the most widely cited best practices in software is so misunderstood.
If you enjoyed this, you should definitely check out the Master feed of all Changelog podcasts. Because have you heard? Monoliths are back in style. While you’re at it, subscribe to Changelog Weekly and join our global hacker community all for the price of a free pretzel. 🥨
Sign in or Join to comment or subscribe
Writing code is an incremental process: don’t try to write “DRY” from the start. Plan to do it, but copy-paste when you don’t know how it’s going to be.
How constraints you give are going to drive the code own logic.
The hardest part - and perhaps the most interesting one - is realizing when something can be factored, which feels good indeed, and when something cannot be factored, which feels suspicious ! A new concept (interface) might be needed.