Nicely put. The problem with DRY is it is expressed in term of "repeating" so it suggests that code repetition is the problem. The flip side of achieving DRY is

Nicely put. The problem with DRY is it is expressed in term of "repeating" so it suggests that code repetition is the problem. The flip side of achieving DRY is breaking isolation between two pieces of code. That's a downside - so DRY is a tradeoff, not a simple one sided win. The real questions are things like "Is it likely if I change logic A, that B will also need to change in the same way?" and "Is it likely that if there's a bug in B, that would also be a bug in A?". If those things aren't true, you are shooting yourself in the foot because you will certainly be going in and changing A and B to maintain them and now every time you do that for one you are at risk of breaking the other. DRY is usually right, but it definitely comes at a cost.