Rule #3 - Never Write the Same Code Twice

Welcome to the third rule of The Programmer's Code, Never Write the Same Code Twice.

Have you ever played whack-a-mole? It's the carnival game where you try to hit the mole when it pops out of one of several holes before it quickly disappears again. The game can leave you frantically swinging for moles all over the board and missing most of them. It reminds me of a developer trying to fix bugs in a program with a lot of duplicate code.

Champion Whack-A-Mole Player on YouTube

If the whack-a-mole example is hard to visualize, then maybe you've seen plate spinners. They balance numerous plates on poles. As long as the plates are spinning, they'll stay on the pole, but if they slow down too much they'll fall off. The challenge of the plate spinner is to keep as many plates spinning simultaneously on the top of the poles as possible. Usually, the plate spinner is running around like a mad man trying to keep all the plates spinning. This is what it's like trying to maintain software with lots of duplicate code.

Plate Spinner Chaos on YouTube

Circus Software

If you haven't guessed by now, I think writing duplicate code is bad. Maintaining your software with duplicate code can become a circus of craziness.

I am personally guilty of violating all of the rules in The Programmer's Code on many occasions. This is the reason I'm so convinced of the importance of each and every one of these rules. I have a full and complete understanding of the consequences based on personal experience. When it comes to writing duplicate code I've been burned many times. It often seems easier to cut and paste than to reconsider the design of the code. Things may be simpler in the short run, but there is a high long-term price.

Many developers fall into this trap and many team leads or business leaders who are desperate to finish a project push their developers to just get it done.

Usually, everyone has good intentions. I get that. But you always pay a bigger price later.

Some of the smartest developers I know are guilty of having very disorganized code. That's because they are more skilled than the rest of us and holding a large number of unrelated facts in their heads. They can remember the sixteen different places where they used that clever parsing code...

...At least for a while...

If you've been coding more than three months, you've had the bizarre experience of working on a piece of code and mumbling under your breath about the S.O.B that wrote it only to suddenly realize that S.O.B was you. I've experienced this many times. No shame, we all do it. What this tells me is that no matter how good you are at keeping lots of facts in your head, it doesn't take long before you start forgetting them.

Three months on, a bug is discovered in that parsing code of yours and now you have to go fix it in all fifteen places. Awesome. Done. That wasn't so hard?

Did I say fifteen? Or was it sixteen? I forget.

If the code for parsing URLs, for example, exists in just one place that means:

• less time finding the code to change
• less time changing the code
• smaller likelihood of missing code that needs to be changed
• smaller likelihood of bugs
• greater confidence that the problem was fully resolved

Southwest Efficiency

There's a reason Southwest Airlines is the most consistently profitable airline in history.

You may have heard that Southwest uses only one type of aircraft. They have about five hundred and fifty Boeing 737s. By having only one aircraft type, they train one set of mechanics, they buy one set of tools, they create one set of documentation. If they purchased a single aircraft of another type, they would have to double their mechanic training, their toolsets and their documentation, even though that one aircraft was only a tiny fraction of their whole fleet. That wouldn't be very efficient.

Southwest recently purchased another airline using a different type of aircraft. Thus bringing their total number of aircraft types to about two. Time will tell if they can remain as profitable.

In software, two copies of the same code is very inefficient and something to avoid.

Your Most Powerful Design Tool

Rule #3, Never Write the Same Code Twice, falls under one of three categories of rules: Daily Disciplines.

The other two categories are Design Disciplines and Attitudes.

I could argue that Rule #3 is really a Design Discipline, but I put it under Daily Disciplines because it is something you must consider every day while coding--not just during the design phase.

In my opinion, Never Write the Same Code Twice is the single most important and powerful design tool available to the developer.

If you knew nothing about design, but followed this one rule, your code would be reasonably well organized and easy to maintain. If you think about it, all of the rules and tools of object oriented design are created so that we can minimize duplicate code.

Imagine you are designing a car using object oriented techniques. First you have a car object. Add some wheel objects. Then an engine object. And an ignition object. Each of these objects can do something. If you want to start the car, you use the ignition object. The ignition would be the one object with the code to start the car.

Can you imagine putting the "StartCar" code in the wheel object, also? Wow, I can start the car from the ignition or the wheel. Isn't that cool?

Hopefully, it's obvious from this example how silly that is. But we encounter similar situations every day that may be more subtle, but where duplicate code is no less ridiculous.

When I find myself writing or copying blocks of code I've already written, this is a giant red-flag. I know my design needs some attention. Usually, it doesn't take much effort to come up with a way to eliminate the duplication. Sometimes it is as simple as encapsulating the code in a method which can be called from multiple places.

Never is a Strong Word

This rule, Never Write the Same Code Twice, begins with the word never. That's some serious language. Is there ever a case where writing duplicate code is acceptable?

If you want good code, never break this rule. However, there are compromises in business and in life. And often these concerns outweigh a developer's concerns. This can be frustrating, but it is important for us to remember. If a business could fail because the software isn't done, then getting something out the door and refactoring later may be the better option. Situations such as this are why The Programmer's Code has Rule #27, Rules are best broken by those who have mastered them. Use this rule sparingly, but without shame.

Making compromises in software can be frustrating, but don't despair. Remember the words of the great Master Po:

• Young Caine: "Master, forgive me for I have failed."
• Master Po: "You have failed no one, Grasshopper, only your own ambition."