The DRY principle sometimes forces the programmers to write complex, hard-to-maintain functions/classes. Code like this has a tendency to become more complex and harder to maintain over time. Violating the KISS principle.
For example, when multiple functions needs to do something similar. The usual DRY solution is to write a function that takes different parameters to allow for the slight variations in usage.
The upside is obvious, DRY = one place to make changes, etc.
The downside and the reason it's violating KISS is because functions like these have a tendency to become more and more complex with more and more parameters over time. In the end, the programmers will be very afraid to make any changes to such functions or they will cause bugs in other use cases of the function.
Personally I think it makes sense to violate DRY principle to make it follow KISS principle.
I would rather have 10 super simple functions that are similar than to have one super complex function.
I would rather do something tedious, but easy (make the same change or similar change in 10 places), than make a very scary/difficult change in one place.
Obviously the ideal way is to make it as KISS as possible without violating DRY. But sometimes it seems impossible.
One question that comes up is "how often does this code change?" implying that if it changes often, then it's more relevant to make it DRY. I disagree, because changing this one complex DRY function often will make it grow in complexity and become even worse over time.
So basically, I think, in general, KISS > DRY.
What do you think? In which cases do you think DRY should always win over KISS, and vice versa? What things do you consider in making the decision? How do you avoid the situation?
Best Answer
KISS is subjective. DRY is easy to over apply. Both have good ideas behind them but both are easy to abuse. The key is balance.
KISS is really in the eye of your team. You don't know what KISS is. Your team does. Show your work to them and see if they think it's simple. You are a poor judge of this because you already know how it works. Find out how hard your code is for others to read.
DRY is not about how your code looks. You can't spot real DRY issues by searching for identical code. A real DRY issue could be that you're solving the same problem with completely different looking code in a different place. You don't violate DRY when you use identical code to solve a different problem in a different place. Why? Because different problems can change independently. Now one needs to change and the other doesn't.
Make design decisions in one place. Don't spread a decision around. But don't fold every decision that happens to look the same right now into the same place. It's ok to have both x and y even when they both are set to 1.
With this perspective I don't ever put KISS or DRY over the other. I don't see nearly the tension between them. I guard against abuse of either. These are both important principles but neither is a silver bullet.