Do Repeat Yourself (Sometimes)

Everybody knows the DRY principle¹, and it makes a lot of sense. You really don’t want to have to copy and paste the same code over and over again. But I’d say that, even worse than copying the same code, is building out a common code base that doesn’t grow very well. As we add functionality, we want to do so in a way that doesn’t conflict with the general purpose of the area that we’re adding the code to as a conflict in purpose creates an existential problem.

The beauty of copy and pasting a small section of code is that that piece of code now exists to serve only a single purpose - whatever you’re currently working on at the time. If, instead, you chose to either use an existing library, add your new functionality to an existing library, or create a new library, you now have a relationship between two distinct entities. When these two entities exist symbiotically, you’re in a good place, and there are few to no issues to deal with.

However, when these two entities exist in conflict with each other, you will get a war, and the conflict must be resolved by either divorcing the two or making a change to bring about some semblance of peace. But every treaty drafted for the purpose of bringing about peace with your neighbor to the South can have the additional effect of bringing conflict with your neighbor to the North, which will have to be resolved in turn.

How do we square this circle? Just like nation states live under a system of anarchy, so does the software world. Each relationship must be treated differently and must follow different rules.

In investing, there’s a principle called “Opportunity Cost²”. The idea being that each investment has a cost associated with it. Obviously, if your goal is to end up with more money, you pick investments that will put you in a better position after the period of time for which you are investing. You don’t have an infinite supply of capital.

The same principle can be applied to the software world. You don’t have to purchase any investment. Sometimes, you just want to keep your money in cash because either the solution you want will exist in the near-term future or you just don’t yet have enough confidence with the choice you’re leaning toward. If you keep each piece of your project separate, you will have many, distinct nations that don’t interact and yet don’t conflict with each other.

However, if you start placing smart investments between them, the different nations will begin to trade, and the system as a whole may be able to produce the same amount of goods or more for the same amount of cost or lower. This may bring about a momentary period of peace and prosperity where a library exists for a well-defined purpose, and each use of it adheres to that purpose. But some relationships may demand more from the library and cause a schism in purpose.

It’s when these relationships become convoluted and outlive their welcome that conflict arises, and you begin to lose money or produce less in the long-term. As I stated a couple of months ago, the world of software is not “settled” just like the real world is not “settled”. There is no “lived-in” solution that can’t crumble in the next instant.