If it's domain logic, like calculating the total for a shopping cart then you gotta follow DRY. The risk of application inconsistencies are too high. But if it's anything else then I go with KISS.

I really think DRY is far more important for business logic than it is for infrastructure logic. If you calculate what taxes someone owes in two different ways that's terrible. If you serialize two different things in your application in two different ways, probably doesn't matter.

The thing about DRY is it's not just "don't repeat this code," it's "don't repeat this code that has the same execution assumptions and maintenance expectations." You can make those assumptions broader with parameterization, injection, etc., but there's a limit before you either make it too complex to reason through or end up pulling in diverse maintenance expectations.

In my own niche, software test automation, this can be a huge problem because the meat of every test stands alone from all other tests, otherwise it wouldn't be a unique and interesting test. Applying DRY naively in that kind of situation often leads to a bunch of non-cohesive "do everything but this, and based on this flag do this one different thing" type code.

You really have to jump back a level and look at things more in context of their usage. This is one of the reasons that there's debate about even sharing things like setup methods, never mind test bodies.

Sounds like the evolution of different flows described has a lot in common with this. You have to look past the lexical.

I think of the combination as DRY KISS - do repeat yourself to keep it simple, stupid!