software solutions / project leadership / agile coaching and training

Balancing DRY and readability

Posted on February 24, 2014

We all love the DRY principle (Don’t Repeat Yourself). It really is a good idea, we don’t want to have two places in the code that do the same thing, and we want good object-oriented design. But even DRY can go too far.

Recently I’ve run into some cases where DRY decreases the readability of the code. I had some simple classes to write that do some relatively simple calculations, and the business rules are fairly similar to some other classes that exist, but with a few differences. I started down the path of making one class that can handle all situations, with hooks for modifying the behavior of the class (either virtual methods or configuration settings somewhere else).

This is all well and good until you realize that now you’ve taken something simple and turned it into something really complicated that even you have a hard time understanding anymore.

DRY is great, but I lost sight of why DRY is good. DRY is good because it makes code more maintainable, more consistent, and easier to understand and add new functionality. But as soon as DRY stops providing those benefits, maybe it’s time to keep things simple and just write readable code that makes sense, even if it means you have a little bit of duplication.

1 Comment »

  1. Avdi Grimm did two RubyTapas episodes on the concept of Coincidental Duplication. (episodes #89 and #92)

    In those episodes, he points out that the core of DRY is about eliminating the duplication of knowledge in a system (specifically, domain knowledge). If there are two distinct pieces of knowledge that are *coincidentally* implemented in a similar fashion, that doesn’t mean they should be combined. The similarity in structure does not imply a shared domain concept or shared piece of knowledge.

    I like this idea because it clearly explains cases in my own experience where a DRY-focused refactor made the code worse. In those instances, it was clearly a coincidental structural similarity in the code. In fact, one easy way to spot the difference is to think about how two similar chunks of code would change. If it would ever make sense that one would change without the other, then it’s very possible that the similarity is structural, coincidental (and perhaps even temporary). If, on the other hand, two similar chunks of code will likely change in concert, then that’s an indication that they share a domain concept. As such, the duplication should be removed.

    In short, finding the nuance in what is DRY vs what is coincidental duplication usually makes clear what would be a good refactoring and what wouldn’t.

    Jason — February 24, 2014 @ 9:06 pm

Leave a comment

I have over 15 years of software development experience on several different platforms (.NET, Ruby, JavaScript, SQL Server, and more). I recognize that software is expensive, so I'm always trying to find ways to speed up the software development process, but at the same time remembering that high quality is essential to building software that stands the test of time.
I have experience leading and architecting large Agile software projects and coordinating all aspects of a project's lifecycle. Whether you're looking for technical expertise or someone to lead all aspects of an Agile project, I have proven experience from multiple projects in different environments that can help make your project a success.
Every team and every situation is different, and I believe that processes and tools should be applied with common sense. I've spent the last 10+ years working on projects using Agile and Lean concepts in many different environments, both in leadership roles and as a practitioner doing the work. I can help you develop a process that works best in your organization, not just apply a prescriptive process.
Have any questions? Contact me for more information.
Ditching the Office - How an everyday corporate development team turned into a remote working team
From Stir Trek 2018
From Stir Trek 2017, cbus.js 2017
Iteration Management - Your Key to Predictable Delivery
From Stir Trek 2016 and QA or the Highway 2015
From CodeMash 2016, QA or the Highway 2014, Stir Trek 2012
The Business of You: 10 Steps For Running Your Career Like a Business
From CodeMash 2015, Stir Trek 2014, CONDG 2012
From Stir Trek 2013, DogFoodCon 2013
(presented with Brandon Childers, Chris Hoover, Laurel Odronic, and Lan Bloch from IGS Energy) from Path to Agility 2012
From CodeMash 2012 and 2013
(presented with Paul Bahler and Kevin Chivington from IGS Energy)
From CodeMash 2011
An idea of how to make JavaScript testable, presented at Stir Trek 2011. The world of JavaScript frameworks has changed greatly since then, but I still agree with the concepts.
A description of how test-driven development works along with some hands-on examples.
From CodeMash 2010
From CodeMash 2010