On ‘The Evils of Duplication’

and keeping your code DRY

Apparently good ideas about how to program, like rubber duck debugging and the concept of keeping your code DRY come from The Pragmatic Programmer by Andrew Hunt and David Thomas. We are introduced to it in one of the first essays in the book, ‘The Evils of Duplication’. While we’re immediately reminded of the time that Captain Kirk disabled out of control AI by giving the computer contradictory knowledge, we’re just as quickly thrust back into reality. Life is not sci-fi, contradictory knowledge in your work is far more likely to bring your code down, and as programmers, our job is to avoid that at all costs. An excellent method used far and wide to help keep your code neat and your web apps running is just Don’t Repeat Yourself, keep it DRY.

Duplicitation is rarely a good thing.

Programming is a maintenance game in both the short and long term. Contrary to what you might think maintenance starts well before an application is released; it’s constant. When you’re first learning to code maintenance is often the furthest thing from your mind. The idea that you’ll be building something that has to be updated and adapted, and possibly last for years after you’ve moved on is kind of a wild concept, and often the furthest thing from your mind. When all you want to do is get data on the DOM you’ll do it by any means, even if those means mean you’re copying and pasting the same three lines of code with one tiny difference, multiple times in the same function. And this is fine for now, get that data on the page! Just always know that it’s not sustainable and that refactoring in the spirit of DRYness is in your future.

“As programmers, we collect, organize, maintain, and harness knowledge. We document knowledge in specifications, we make it come alive in running code, and we use it to provide the checks needed during testing.” — ‘The Evils of Duplication’ from “The Pragmatic Programmer” by Andrew Hunt & David Thomas

As you develop your skills it’s important to start considering the long-term over the immediate as soon as you can wrap your brain around it. Knowing that the ultimate goal is the maintenance of your code and considering that every time you successfully create a feature your goal is to make it as DRY as possible will help not only the readability of your code in the moment, but will help prevent a tangled mess of broken code and an abundance of emotions in the future. I don’t know about you, but when Snail-o-gRama takes off and BookFacer buys it for millions, and your code is passed off to a team of Flatiron grads eager to make the best damn social media photo editing and sharing app the world has ever seen you don’t want your files to be WET (because it Wastes Everyone’s Time when you Write Everything Twice), you don’t want them to look like this.

You don’t ever want to be the one to blame for this beautiful mess.

So what are the actual problems with duplication in your code? You know where you’ve written the same things in a few different places. When you change one you’ll totally remember to change all of them. Right? I mean, you will right? Truth is you might remember sometimes, but inevitably you will forget and best case is you throw a big old in your face error with a beautiful error message telling you exactly what’s wrong, but honestly, it’ll probably be one of those pesky secret silent errors that you won’t notice until all the complaints start coming in about functionality that you thought was working fine is actually broken and now Snaily Berry can’t see the likes on her sexy Catwoman Halloween costume pics on Snail-o-gRama.

“Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.” — ‘The Evils of Duplication’ from “The Pragmatic Programmer” by Andrew Hunt & David Thomas

When utilizing the DRY programming principle, the goal is to reduce the repetition of data, and there are several methods you can employ to aid in success in this goal and I’ll talk about a few of them. First up is abstraction, a programming principle on its own, it folds in nicely with DRY as both principles have the common goal of avoiding duplication. It “aims to reduce duplication of information in a program… whenever practical by making use of abstractions provided by the programming language…”¹

This is ok because there’s only two of them.

Next up is the Rule of Three. The rule of three is pretty simple. If your code is identical in 3 or more places, abstract that ish down! It’s the rule of three for a reason; the rule of three states, “two instances of similar code don’t require refactoring, but when similar code is used three times, it should be extracted into a new procedure”.² Classes, methods, functions, et al, they’re your friends! They’re both easy to maintain and to reuse, so use them. Because two’s company, but three is broken code.

Delete your code with the confidence of David. You don’t need it!

Last DRY co-method I’ll talk about in this post is You Aren’t Going to Need It (YAGNI). This is just about going back in and removing anything you don’t need. All those lines of code you commented out because you didn’t want to lose it just in case? (I’m totally guilty of this). Once you know you don’t need it, delete it. Cluttered code is so hard to sift through and read, when you’re refactoring and everything is up and working just get rid of what you’re not using. As long as you’re committing your work to your git, or using source control while you work this shouldn’t be scary because you can always revisit your old working code.

And the last thing I’ll mention in this post are types of duplication. There are four main categories, the four ‘I’s’ and they are:

• Imposed duplication — you feel you don’t have another choice, something in your code seems to require the duplication.
• Inadvertent duplication — whoops. You don’t realize that you’ve duplicated that code!
• Impatient duplication — You’ve been working for hours, you know this one piece works and will work for this other part, so you duplicate because you’re human, sometimes you get lazy and you take the seemingly easier path (but it’s not actually easier, it just seems easier in the moment! Just wait for that big update where this path of least resistance leads to broken code).
• Interdeveloper duplication — Probably the most forgivable, you’re working with a team and another developer duplicates some data you’ve already created.

I’ll go more in-depth on these kinds of duplication in another post. Being able to recognize why your code is duplicated is a huge benefit to keeping it DRY. So until next time.

DRY me a river.

Resources

The Pragmatic Programmer by David Thomas, Andrew Hunt

https://metova.com/dry-programming-practices/

¹https://en.wikipedia.org/wiki/Abstraction_principle_(computer_programming)

²https://en.wikipedia.org/wiki/Rule_of_three_(computer_programming)