3 ms·

Every time you consider copy pasting, you should be asking yourself “if the stuff I’m pasting needs to change, will I want both of these places to change?” It r

Every time you consider copy pasting, you should be asking yourself “if the stuff I’m pasting needs to change, will I want both of these places to change?” It requires some guessing the future, but usually it’s not hard to answer the question. IME if something should be an independent function or module, I rarely get to the point of considering copy/pasting it in the first place. If I want to copy/paste it’s usually because the two places currently only incidentally need the same code now, and my gut usually tells me that it will no longer be the case if I have to make any sort of change.

mewpmewp2 2y ago
Early in my career I started out really DRY, it in my experience and not just the code I wrote led to various issues down the line with unmaintainable edge cases. Especially if many teams are working on those things. It becomes really hard to support at some point. Now I feel much better making things DRY when it is really obvious that it should be.
- dllthomas 2y ago
  > I started out really DRY When you say "DRY" here, would you say you had familiarity with the original definition, or merely what you (quite understandably) inferred from the acronym? Because I think the formulation in The Pragmatic Programmer is pretty spot on in speaking about not repeating "pieces of information", whereas I find in practice most people are reacting to superficial similarity (which may or may not reflect a deeper connection).
  - mewpmewp2 2y ago
    Looking at the definition, I do believe I wasn't referring to the original definition. I didn't actually know that original definition was specifically limited to the information/knowledge part. I have to assume there's industry wide misunderstanding on this term? To avoid the confusion, it seems like DRY would be better named something like "Single source of truth". Because I do agree with that.
    - dllthomas 2y ago
      > I have to assume there's industry wide misunderstanding on this term? The "misunderstanding" is at least as prevalent as the original, yes. I wasn't trying to say the original is "correct" - language is determined by usage - just wondering which you were discussing. > To avoid the confusion, it seems like DRY would be better named something like "Single source of truth". It could probably do with a better name, but "single source of truth" is usually about the information operated on by the program, rather than information embodied in the program.
      - mewpmewp2 2y ago
        You mean it's databases rather than what is in code? If so, then that's also news to me. I'd have thought that e.g. something like input validation code that can be reused both in backend and client would go under single source of truth. Which I would always prefer not to be repeated, but frequently hard to do unless you have same language in backend and frontend or codegen.
        dllthomas 2y ago
        With a sufficiently broad definition of "database", yeah, that's my understanding.
hinkley 2y ago
And usually the answer stops becoming a guess at 3. I’ve certainly had enough experiences where we had 2 and 3 in the backlog and no matter how we tried, #3 always required as much or more work than #2 because we guessed wrong and it would have been faster to slam out #2 and let #3 be the expensive one.

mewpmewp2 2y ago

Early in my career I started out really DRY, it in my experience and not just the code I wrote led to various issues down the line with unmaintainable edge cases. Especially if many teams are working on those things. It becomes really hard to support at some point. Now I feel much better making things DRY when it is really obvious that it should be.

dllthomas 2y ago
> I started out really DRY When you say "DRY" here, would you say you had familiarity with the original definition, or merely what you (quite understandably) inferred from the acronym? Because I think the formulation in The Pragmatic Programmer is pretty spot on in speaking about not repeating "pieces of information", whereas I find in practice most people are reacting to superficial similarity (which may or may not reflect a deeper connection).
- mewpmewp2 2y ago
  Looking at the definition, I do believe I wasn't referring to the original definition. I didn't actually know that original definition was specifically limited to the information/knowledge part. I have to assume there's industry wide misunderstanding on this term? To avoid the confusion, it seems like DRY would be better named something like "Single source of truth". Because I do agree with that.
  - dllthomas 2y ago
    > I have to assume there's industry wide misunderstanding on this term? The "misunderstanding" is at least as prevalent as the original, yes. I wasn't trying to say the original is "correct" - language is determined by usage - just wondering which you were discussing. > To avoid the confusion, it seems like DRY would be better named something like "Single source of truth". It could probably do with a better name, but "single source of truth" is usually about the information operated on by the program, rather than information embodied in the program.
    - mewpmewp2 2y ago
      You mean it's databases rather than what is in code? If so, then that's also news to me. I'd have thought that e.g. something like input validation code that can be reused both in backend and client would go under single source of truth. Which I would always prefer not to be repeated, but frequently hard to do unless you have same language in backend and frontend or codegen.
      - dllthomas 2y ago
        With a sufficiently broad definition of "database", yeah, that's my understanding.

hinkley 2y ago

And usually the answer stops becoming a guess at 3. I’ve certainly had enough experiences where we had 2 and 3 in the backlog and no matter how we tried, #3 always required as much or more work than #2 because we guessed wrong and it would have been faster to slam out #2 and let #3 be the expensive one.