[bunderbunder]

Reminds me of a point in the interview with Donald Knuth in Coders at Work where he criticized overuse of abstraction in code, and said that he thinks it's more important for code to be easy to read and edit than for it to be easy to reuse.

He didn't say it explicitly, but the implication that I took was that things that are meant, in essence, to make code more configurable can sometimes (often?) do more harm than good. (SOLID, I'm looking at you.) Using them successfully often requires oracular knowledge about how the code might evolve in the future.

I've found that doing my job got a lot easier after I started following this idea. The code might be more repetitive and boilerplate-y, but there's actually less of it, so it's still easier to read, understand, and maintain.

[thesnide]

That. YAGNI >> DRY.

The DRY should be obvious when to refactor, not because of some compulsive behavior.

And then once you need more than 2 branches, please break the DRY that tend to stay forever.

[bunderbunder]

I really like the way functional programmers tend to think about factoring code. There's more of a tendency to think in terms of creating algebras. That forces you to think a lot more carefully about what abstractions you're producing, why, and how they relate to your domain model. And to be more cautious about it.

DRY, by comparison, is an almost offensively crude heuristic.