DRY or not?

Last Update: 04.04.2018. By Jens in Developers Life | Learning | Newsletter

DRY is another principle and commonly riding along the other two. DRY stands for don’t repeat yourself; meaning “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system” aka writing that piece of code, schema, whatever once for the entire system and re-use. Don’t duplicate code if it’s logically related.

It’s a principle which I see skeptically. On one side, I don’t like repeating stuff and am a fan of writing it once and re-use it. However, this also has a downside as we might not need the whole “code-business-logic-whatever” always in the same manner. Often edge uses-cases arise, or are the norm anyway, and make us extend that single “code-business-logic-whatever” thing again. Now it is covering more edges and thus making it more complicated and harder to use. Not necessarily, but I’ve seen it happen quite too often.

We could argue now if such a thing would be the DRY at all. For me, it is, at least for the “don’t repeat yourself”-part. Even in it’s simplest version, it has drawback we should be aware of. For example, let’s say we have Person object and we wrote it once, so there is only one class in the entire system. Now we are sharing it with other microservices in the same system. Bamm, now we got a hard dependency on a single class. And if it changes, the chances are high we have to update all services… It would not work great with a microservice pattern, which primary goal is the speed of change.

Which leads me to the other side. Repetition can be good sometimes and more valuable than the consequences of “don’t repeat yourself”. Take shell scripts for example. Would you rather copy and paste an existing script and adjust it too your needs or refactor the source script to handle the old and your new use case?

What brings the most business value?