[phamilton]

The point I saw (and heartily agree with) is to be deliberate. DRY is an optimization. What is the cost of DRY? What are the costs of not being DRY?

I think we frequently fall into the trap of doing DRY "because we're supposed to" rather than on a case by case basis evaluating whether or there is a net expected benefit.

That doesn't always mean taking a hard YAGNI line. There are plenty of opportunities for DRY that don't incur a big cost but enable simplicity in future development. It's fairly simple math (though it requires some degree of arbitrary numbers). <Expected cost of refactor (time and added complexity)> vs <Expected benefit (saving future time)> * <Likelihood you will need to update this code>

If you know you're most likely going to revisit the codebase in a month and it's a fairly simple refactor then go ahead and do it.

[alexandercrohde]

>> "Dry is an optimization. What is the cost of DRY? What are the costs of not being DRY?"

Agreed 100%.

I actually made a javascript programming game to try to find explore that balance: http://alexrohde.com/zennish/index.html#/challenges