Design Patterns: DRY

A while ago, I was working with a younger man and as I was doing a code review, I came across some code that looked kind of like this:

readColumnA () {
      columnA = columnReader("columnA");
      processColumn(columnA);
}

readColumnB () {
      columnB = columnReader("columnB");
      processColumn(columnB);
}

It isn’t really important what was in the file, or what the processing being done was.  These two methods are basically identical, the only difference is the value passed to columnReader.

I suggested that he change this code to look more like this:

columnProcessor (String columnName) {
      column = columnReader(columnName);
      processColumn(column);
}

Then, you could call it for each column you need to process.

When you remove duplication like this you are making your code DRY.  DRY stands for don’t repeat yourself.  In the first example you can see that we repeated the algorithm for processing the columns for each column we needed to process.  We can see that the only thing that changed was the column name, and extract that part out, and then have a generic method to process columns.

My colleague had heard of DRY, but thought that he shouldn’t use it here since he was pretty sure that we would change and want to process columnA differently than columnB in the future.  While this argument makes a certain amount of sense, we need to remember that we are not psychic, and while we can speculate on how a software project might evolve, we are never really sure.  The requirements and priorities change under our feet, and our guesses are often wrong.

In my opinion, and in my experience it is always better to keep your code clean because you want to be able to make changes easily.  If, at some point, in the example above, column A and column B processing diverge, then (and only then) you should change the code to accommodate this.

 

There are three ways to do things…

Homer: …the right way, the wrong way and the Max Power way
Bart: Isn’t that the wrong way?
Homer: Yeah, but faster!

Is there such a thing as “the right way” in software engineering?

Earlier in my career, I was an idealist.  I wanted to do things “the right way”, always.  I hated when the business would push for things to get done sooner, which usually meant taking shortcuts.  I pushed back, and sometimes I got my way, and sometimes I didn’t.  I complained that by going faster, we were just digging ourselves into a hole and I just knew that we wouldn’t ever go back to fix some of the shortcuts we made.

Now I am in charge of a product which I am also the lead developer and architect on (small company).  I find myself wanting to use a phrase that I really dislike: “Perfect is the enemy of good enough.”  (I never liked that phrase, because I had seen it used to push teams to cut way too many corners both in development, as well as product design.)

I find myself telling my colleague things like “ideally we would do x this way, but we are on a tight deadline, so we will have to do it this other way”.  (I typically put in a card to go back and fix the shortcut later.)  I really enjoy that he pushes me to do things the right way rather than taking shortcuts, because I know I shouldn’t, but I am feeling a lot of pressure.

But, we don’t live in a black and white world.  We live in a world with lots of (fifty)shades of gray (and lots of other colors to boot).

One of my nieces just started college, and she is taking a course in programming.  I was talking to her about it last week, and she said she didn’t really like it because there were so many ways to accomplish the same thing.  I didn’t say it to her, but I thought to myself that what she said was true, but there are pros and cons to each of the ways you could do it, and with some experience you can figure those out.

And I think that is what this choice of “the right way” comes down to…using your experience to weigh the pros and cons of doing something one way vs another and making an informed decision.  Sometimes “the right way” in one situation is very much the wrong way in another, and I think we only figure that out with experience.

With experience we can figure out when to break the rules.  And that is ok.