3 ms·

I feel like I hear de-duplication of information / knowledge often referred to as "Single Source of Truth"

derefr 2y ago
I think the best way to understand DRY is by thinking about the practical problem it solves: you don't want footguns in the codebase where you could change something in one place, but forget to change the same thing in other places (or forget to change the complementary logic/data in other components.) The goal of DRY as a refactoring, is first-and-foremost to obviate such developer errors. And therefore — if you want to be conservative about applying this "best practice" — then you could do that by just never thinking "DRY" until a developer does in fact trip over some particular duplication in your codebase and causes a problem.
- rezonant 2y ago
  > you don't want footguns in the codebase where you could change something in one place, but forget to change the same thing in other places This. Ironically the example on TFA is vulnerable to this issue. Each of the deadline setting methods has a copy of the validation ensuring that the date is in the future. If it's discovered that we need to ensure deadlines are set no later than the project deadline (since that wouldn't generally make sense), it's awfully easy to only update one and miss the others, especially after code has been added and these implementations are no longer visually near each other. I'm not saying that this means the code must be DRY'ed, but it is a risk from the beginning of the project, so one that needs to be weighed during initial implementation.
hot_gril 2y ago
The Two Generals Problem is mentioned a lot in databases and networking, and you can take some liberties to extend it to human orgs.
- sham1 2y ago
  > The Two Generals Problem is mentioned a lot in databases and networking, and you can take some liberties to extend it to human orgs. In fact, the name probably already gives some hint as to what sorts of human orgs this sort of principle would be applicable in. And, well, the vast majority of orgs require some sort of coordination.

I think the best way to understand DRY is by thinking about the practical problem it solves: you don't want footguns in the codebase where you could change something in one place, but forget to change the same thing in other places (or forget to change the complementary logic/data in other components.) The goal of DRY as a refactoring, is first-and-foremost to obviate such developer errors. And therefore — if you want to be conservative about applying this "best practice" — then you could do that by just never thinking "DRY" until a developer does in fact trip over some particular duplication in your codebase and causes a problem.

rezonant 2y ago
> you don't want footguns in the codebase where you could change something in one place, but forget to change the same thing in other places This. Ironically the example on TFA is vulnerable to this issue. Each of the deadline setting methods has a copy of the validation ensuring that the date is in the future. If it's discovered that we need to ensure deadlines are set no later than the project deadline (since that wouldn't generally make sense), it's awfully easy to only update one and miss the others, especially after code has been added and these implementations are no longer visually near each other. I'm not saying that this means the code must be DRY'ed, but it is a risk from the beginning of the project, so one that needs to be weighed during initial implementation.

hot_gril 2y ago

The Two Generals Problem is mentioned a lot in databases and networking, and you can take some liberties to extend it to human orgs.

sham1 2y ago
> The Two Generals Problem is mentioned a lot in databases and networking, and you can take some liberties to extend it to human orgs. In fact, the name probably already gives some hint as to what sorts of human orgs this sort of principle would be applicable in. And, well, the vast majority of orgs require some sort of coordination.