4 ms·

In rails shops, "dry" is _always_ overused. It was part of the red->green cycle in TDD culture, and got mentioned in every context, and as a result nearly all l

In rails shops, "dry" is _always_ overused. It was part of the red->green cycle in TDD culture, and got mentioned in every context, and as a result nearly all legacy rails apps are filled with weird abstractions introduced in a commit with a message like "dry it up". The problem is that it's phrased as a rule rather than a smell. DRY deserves to be listed with other code smells that may indicate a missing abstraction (and there are many), but there is never a reason to blindly extract chunks of code based purely on repetition. That's not a "first step toward good programming", it's a step in the wrong direction.

ahallock 4y ago
I've experienced this first-hand in a Rails app, last week in fact. The result was a messy, hard-to-understand hierarchy of classes and abstractions--just because two workflows shared some similarities. Usually I find this happening with hardcore OO programmers or bored programmers who feel the need to start creating and don't know when to stop. I prefer boring code at this stage in my career.
- ParetoOptimal 4y ago
  > just because two workflows shared some similarities. Usually I find this happening with hardcore OO programmers or bored programmers who feel the need to start creating and don't know when to stop. I prefer boring code at this stage in my career. As a Haskeller, when I do this it's about getting certain guarantees about the semantics of related workflows and knowing they must behave the same in X, Y, and Z. This aids in reasoning about inevitable production issues. I find boring code easy to modify but hard to reason about from a higher level and that it typically requires nastier solutions to maintain backwards compatibility. That last point is contradicted by this posts example though, so it has me reflecting on things.
michaelcampbell 4y ago
Thanks; this is about what I was going to say but you said it better. DRY is a tool, not a design goal. I think part of the Rails issue is a combination of the early Rails hype/philosophy, and the fact that DRY as a concept is so easy to "get", that everyone gets it but often fail the next step of "why". Without the why, you often can't figure out the right when/where so it gets applied everywhere. It feels to me like another oblique angle of Goodhart's Law; eg: "A rule of thumb that becomes a required practice ceases to be a good rule of thumb".
- harry-wood 4y ago
  But "early Rails hype/philosophy" is the only thing you've said specifically about Rails. I think I know what you mean though. There are strong philosophies in the Rails (and more generally ruby) communities. Opinionated coding, and software craftsmanship is lauded, more than in other language communities I think. As a result, rules of thumb like DRY are drummed into new developers. The overall effect of that is probably better code quality in general, but yes probably more instances of them being over-used. But if Rails has the problem of folks over-using DRY, what are other languages communities doing? Just not doing so well at telling people about DRY in the first place?

ahallock 4y ago

I've experienced this first-hand in a Rails app, last week in fact. The result was a messy, hard-to-understand hierarchy of classes and abstractions--just because two workflows shared some similarities. Usually I find this happening with hardcore OO programmers or bored programmers who feel the need to start creating and don't know when to stop. I prefer boring code at this stage in my career.

ParetoOptimal 4y ago
> just because two workflows shared some similarities. Usually I find this happening with hardcore OO programmers or bored programmers who feel the need to start creating and don't know when to stop. I prefer boring code at this stage in my career. As a Haskeller, when I do this it's about getting certain guarantees about the semantics of related workflows and knowing they must behave the same in X, Y, and Z. This aids in reasoning about inevitable production issues. I find boring code easy to modify but hard to reason about from a higher level and that it typically requires nastier solutions to maintain backwards compatibility. That last point is contradicted by this posts example though, so it has me reflecting on things.

michaelcampbell 4y ago

Thanks; this is about what I was going to say but you said it better. DRY is a tool, not a design goal. I think part of the Rails issue is a combination of the early Rails hype/philosophy, and the fact that DRY as a concept is so easy to "get", that everyone gets it but often fail the next step of "why". Without the why, you often can't figure out the right when/where so it gets applied everywhere. It feels to me like another oblique angle of Goodhart's Law; eg: "A rule of thumb that becomes a required practice ceases to be a good rule of thumb".

harry-wood 4y ago
But "early Rails hype/philosophy" is the only thing you've said specifically about Rails. I think I know what you mean though. There are strong philosophies in the Rails (and more generally ruby) communities. Opinionated coding, and software craftsmanship is lauded, more than in other language communities I think. As a result, rules of thumb like DRY are drummed into new developers. The overall effect of that is probably better code quality in general, but yes probably more instances of them being over-used. But if Rails has the problem of folks over-using DRY, what are other languages communities doing? Just not doing so well at telling people about DRY in the first place?