6 ms·

DRY is my pet example of this. I've seen CompSci guys especially (I'm EEE background, we have our own problems but this ain't one of them) launch conceptual co

DRY is my pet example of this. I've seen CompSci guys especially (I'm EEE background, we have our own problems but this ain't one of them) launch conceptual complexity into the stratosphere just so that they could avoid writing two separate functions that do similar things.

pydry 6mo ago
DRY is misunderstood. It's definitely a fundamental aspect of code quality it's just one of about 4 and maximizing it to the exclusion of the others is where things go wrong. Usually it comes at the expense of loose coupling (which is equally fundamental). The goal ought to be to aim for a local minima of all of these qualities. Some people just want to toss DRY away entirely though or be uselessly vague about when to apply it ("use it when it makes sense") and thats not really much better than being a DRY fundamentalist.
- layer8 6mo ago
  DRY is misnamed. I prefer stating it as SPOT — Single Point Of Truth. Another way to state it is this: If, when one instance changes in the future, the other instance should change identically, then make it a single instance. That’s really the only DRY criterion.
  - xnorswap 6mo ago
    I like this a lot more, because it captures whether two things are necessarily the same or just happen to be currently the same. A common "failure" of DRY is coupling together two things that only happened to bear similarity while they were both new, and then being unable to pick them apart properly later.
    - CodesInChaos 6mo ago
      > then being unable to pick them apart properly later. Which is often caused by the "midlayer mistake" https://lwn.net/Articles/336262/ https://lwn.net/Articles/336262/
  - mcv 6mo ago
    That's how I understood it. If you add a new thing (constant, route, feature flag, property, DB table) and it immediately needs to be added in 4 different places (4 seems to be the standard in my current project) before you can use it, that's not DRY.
    - mjr00 6mo ago
      > If you add a new thing (constant, route, feature flag, property, DB table) and it immediately needs to be added in 4 different places (4 seems to be the standard in my current project) before you can use it, that's not DRY. The tricky part is that sometimes "a new thing" is really "four new things" disguised as one. A database table is a great example because it's a failure mode I've seen many times. A developer has to do it once and they have to add what they perceive as the same thing four times: the database table itself, the internal DB->code translation e.g. ORM mapping, the API definition, and maybe a CRUD UI widget. The developer thinks, "oh, this isn't DRY" and looks to tools like Alembic and PostGREST or Postgraphile to handle this end-to-end; now you only need to write to one place when adding a database table, great! It works great at first, then more complex requirements come down: the database gets some virtual generated columns which shouldn't be exposed in code, the API shouldn't return certain fields, the UI needs to work off denormalized views. Suddenly what appeared to be the same thing four times is now four different things, except there's a framework in place which treats these four things as one, and the challenge is now decoupling them. Thankfully most good modern frameworks have escape valves for when your requirements get more complicated, but a lot of older ones[0] really locked you in and it became a nightmare to deal with. [0] really old versions of Entity Framework being the best/worst example.
      - mcv 6mo ago
        I believe that was the point of Ruby on Rails: that you really had to just create the class, and the framework would create the table and handle the ORM. Or maybe you still had to write the migration; it's been as while. That was pretty spectacular in its dedication to DRY, but also pretty extreme. But the code I'm talking about is really adding the same thing in 4 different places: the constant itself, adding it to a type, adding it to a list, and there was something else. It made it very easy to forget one step.
  - pydry 6mo ago
    Renaming it doesnt change the nature of the problem. There should often be two points of truth because having one would increase the coupling cost more than the benefits that would be derived from deduplication.
  - Silamoth 6mo ago
    That’s how I understand it as well. It’s not about an abstract ideal of duplication but about making your life easier and your software less buggy. If you have to manually change something in 5 different places, there’s a good chance you’ll forget one of those places at some point and introduce a bug.
  - mosburger 6mo ago
    I said this elsewhere in the comments, but I think there's sort of a fundamental tension that shows up sometimes between DRY and "a function/class should only do one thing." E.g., there might be two places in your code that do almost identical things, so there's a temptation to say "I know! I'll make a common function, I'll just need to add a flag/extra argument..." and if you keep doing that you end up with messy "DRY" functions with tons of conditional logic that tries to do too much. Yeah there are ways to avoid this and you need to strike balances, but sometimes you have to be careful and resist the temptation to DRY everything up 'cuz you might just make it brittler (pun intended).
  - gavmor 6mo ago
    Yes, and there are many different kinds of truth, so when two arise together—we can call this connascence—we can categorize how these instances overlap: Connascence of Name, Connascence of Algorithm, etc.
busfahrer 6mo ago
I think I remember a Carmack tweet where he mentioned in most cases he only considers it once he reaches three duplicates
- whattheheckheck 6mo ago
  Why 3? What is this baseball? Take the 5 Rings approach. The purpose of the blade is to cut down your opponent. The purpose of software is to provide value to the customer. It's the only thing that matters. You can also philosophize why people with blades needed to cut down their opponents along with why we have to provide value to the customer but thats beyond the scope of this comment
  - ta20240528 6mo ago
    "The purpose of software is to provide value to the customer." Partially correct. The purpose of your software to its owners is also to provide future value to customers competitively. What we have learnt is that software needs to be engineered: designed and structured.
    - nradov 6mo ago
      And yet some of the software most valuable to customers was thrown together haphazardly with nothing resembling real engineering.
      - shermantanktop 6mo ago
        If you get lucky doing that you might regret it. Especially with non-technical management. Making software is a back-of-house function, in restaurant terms. Nobody out there sees it happen, nobody knows what good looks like, but when a kitchen goes badly wrong, the restaurant eventually closes.
      - galbar 6mo ago
        These projects quickly reach a point where evolving it further is too costly and risky. To the point that the org owning it will choose to stop development to do a re-implementation which, despite being a very costly and risky endeavor, ends up being a the better choice. This is a very costly way of developing software.
iwontberude 6mo ago
Why do the have to be so smart but so annoying at the same time?
zahlman 6mo ago
I've heard that story a few times (ironically enough) but can't say I've seen a good example. When was over-architecture motivated by an attempt to reduce duplication? Why was it effective in that goal, let alone necessary?
- dasil003 6mo ago
  Buy me a beer and I can tell you some very poignant stories. The best ones are where there is a legitimate abstraction that could be great, assuming A) everyone who had to interact with the abstraction had the expertise to use it, B) the details of the product requirements conformed to the high level technical vision, now and forever, and C) migrating from the current state to the new system could be done in a bounded amount of time. My view is over-engineering comes from the innate desire of engineers to understand and master complexity. But all software is a liability, every decision a tradeoff that prunes future possibilities. So really you want to make things as simple as possible to solve the problem at hand as that will give you more optionality on how to evolve later.
- caminante 6mo ago
  IMHO, it comes down to awareness/probability about the need to future proof or add defensive behavior. The spectrum is [YAGNI ---- DRY] A little less abstract: designing a UX comes to mind. It's one thing to make something workable for you, but to make it for others is way harder.
- mosburger 6mo ago
  I think there is often tension between DRY and "thing should do only one thing." E.g., I've found myself guilty of DRYing up a function, but the use is slightly different in a couple places, so... I know, I'll just add a flag/additional function argument. And you keep doing that and soon you have a messed up function with lots of conditional logic. The key is to avoid the temptation to DRY when things are only slightly different and find a balance between reuse and "one function/class should only do one thing."
  - physicles 6mo ago
aworks 6mo ago
I worked for a company that also had hardware engineers writing RTL. Our software architect spent years helping that team reuse/automate/modularize their code. At a mininum, it's still just text files with syntax, despite rather different semantics.
ericmcer 6mo ago
DRY and KISS were right next to each other which I thought was funny.

pydry 6mo ago

DRY is misunderstood. It's definitely a fundamental aspect of code quality it's just one of about 4 and maximizing it to the exclusion of the others is where things go wrong. Usually it comes at the expense of loose coupling (which is equally fundamental). The goal ought to be to aim for a local minima of all of these qualities. Some people just want to toss DRY away entirely though or be uselessly vague about when to apply it ("use it when it makes sense") and thats not really much better than being a DRY fundamentalist.

layer8 6mo ago
DRY is misnamed. I prefer stating it as SPOT — Single Point Of Truth. Another way to state it is this: If, when one instance changes in the future, the other instance should change identically, then make it a single instance. That’s really the only DRY criterion.
- xnorswap 6mo ago
  I like this a lot more, because it captures whether two things are necessarily the same or just happen to be currently the same. A common "failure" of DRY is coupling together two things that only happened to bear similarity while they were both new, and then being unable to pick them apart properly later.
  - CodesInChaos 6mo ago
    > then being unable to pick them apart properly later. Which is often caused by the "midlayer mistake" https://lwn.net/Articles/336262/ https://lwn.net/Articles/336262/
- mcv 6mo ago
  That's how I understood it. If you add a new thing (constant, route, feature flag, property, DB table) and it immediately needs to be added in 4 different places (4 seems to be the standard in my current project) before you can use it, that's not DRY.
  - mjr00 6mo ago
    > If you add a new thing (constant, route, feature flag, property, DB table) and it immediately needs to be added in 4 different places (4 seems to be the standard in my current project) before you can use it, that's not DRY. The tricky part is that sometimes "a new thing" is really "four new things" disguised as one. A database table is a great example because it's a failure mode I've seen many times. A developer has to do it once and they have to add what they perceive as the same thing four times: the database table itself, the internal DB->code translation e.g. ORM mapping, the API definition, and maybe a CRUD UI widget. The developer thinks, "oh, this isn't DRY" and looks to tools like Alembic and PostGREST or Postgraphile to handle this end-to-end; now you only need to write to one place when adding a database table, great! It works great at first, then more complex requirements come down: the database gets some virtual generated columns which shouldn't be exposed in code, the API shouldn't return certain fields, the UI needs to work off denormalized views. Suddenly what appeared to be the same thing four times is now four different things, except there's a framework in place which treats these four things as one, and the challenge is now decoupling them. Thankfully most good modern frameworks have escape valves for when your requirements get more complicated, but a lot of older ones[0] really locked you in and it became a nightmare to deal with. [0] really old versions of Entity Framework being the best/worst example.
    - mcv 6mo ago
      I believe that was the point of Ruby on Rails: that you really had to just create the class, and the framework would create the table and handle the ORM. Or maybe you still had to write the migration; it's been as while. That was pretty spectacular in its dedication to DRY, but also pretty extreme. But the code I'm talking about is really adding the same thing in 4 different places: the constant itself, adding it to a type, adding it to a list, and there was something else. It made it very easy to forget one step.
- pydry 6mo ago
  Renaming it doesnt change the nature of the problem. There should often be two points of truth because having one would increase the coupling cost more than the benefits that would be derived from deduplication.
- Silamoth 6mo ago
  That’s how I understand it as well. It’s not about an abstract ideal of duplication but about making your life easier and your software less buggy. If you have to manually change something in 5 different places, there’s a good chance you’ll forget one of those places at some point and introduce a bug.
- mosburger 6mo ago
  I said this elsewhere in the comments, but I think there's sort of a fundamental tension that shows up sometimes between DRY and "a function/class should only do one thing." E.g., there might be two places in your code that do almost identical things, so there's a temptation to say "I know! I'll make a common function, I'll just need to add a flag/extra argument..." and if you keep doing that you end up with messy "DRY" functions with tons of conditional logic that tries to do too much. Yeah there are ways to avoid this and you need to strike balances, but sometimes you have to be careful and resist the temptation to DRY everything up 'cuz you might just make it brittler (pun intended).
- gavmor 6mo ago
  Yes, and there are many different kinds of truth, so when two arise together—we can call this connascence—we can categorize how these instances overlap: Connascence of Name, Connascence of Algorithm, etc.

busfahrer 6mo ago

I think I remember a Carmack tweet where he mentioned in most cases he only considers it once he reaches three duplicates

whattheheckheck 6mo ago
Why 3? What is this baseball? Take the 5 Rings approach. The purpose of the blade is to cut down your opponent. The purpose of software is to provide value to the customer. It's the only thing that matters. You can also philosophize why people with blades needed to cut down their opponents along with why we have to provide value to the customer but thats beyond the scope of this comment
- ta20240528 6mo ago
  "The purpose of software is to provide value to the customer." Partially correct. The purpose of your software to its owners is also to provide future value to customers competitively. What we have learnt is that software needs to be engineered: designed and structured.
  - nradov 6mo ago
    And yet some of the software most valuable to customers was thrown together haphazardly with nothing resembling real engineering.
    - shermantanktop 6mo ago
      If you get lucky doing that you might regret it. Especially with non-technical management. Making software is a back-of-house function, in restaurant terms. Nobody out there sees it happen, nobody knows what good looks like, but when a kitchen goes badly wrong, the restaurant eventually closes.
    - galbar 6mo ago
      These projects quickly reach a point where evolving it further is too costly and risky. To the point that the org owning it will choose to stop development to do a re-implementation which, despite being a very costly and risky endeavor, ends up being a the better choice. This is a very costly way of developing software.

iwontberude 6mo ago

Why do the have to be so smart but so annoying at the same time?

zahlman 6mo ago

I've heard that story a few times (ironically enough) but can't say I've seen a good example. When was over-architecture motivated by an attempt to reduce duplication? Why was it effective in that goal, let alone necessary?

dasil003 6mo ago
Buy me a beer and I can tell you some very poignant stories. The best ones are where there is a legitimate abstraction that could be great, assuming A) everyone who had to interact with the abstraction had the expertise to use it, B) the details of the product requirements conformed to the high level technical vision, now and forever, and C) migrating from the current state to the new system could be done in a bounded amount of time. My view is over-engineering comes from the innate desire of engineers to understand and master complexity. But all software is a liability, every decision a tradeoff that prunes future possibilities. So really you want to make things as simple as possible to solve the problem at hand as that will give you more optionality on how to evolve later.
caminante 6mo ago
IMHO, it comes down to awareness/probability about the need to future proof or add defensive behavior. The spectrum is [YAGNI ---- DRY] A little less abstract: designing a UX comes to mind. It's one thing to make something workable for you, but to make it for others is way harder.
mosburger 6mo ago
I think there is often tension between DRY and "thing should do only one thing." E.g., I've found myself guilty of DRYing up a function, but the use is slightly different in a couple places, so... I know, I'll just add a flag/additional function argument. And you keep doing that and soon you have a messed up function with lots of conditional logic. The key is to avoid the temptation to DRY when things are only slightly different and find a balance between reuse and "one function/class should only do one thing."
- physicles 6mo ago

aworks 6mo ago

I worked for a company that also had hardware engineers writing RTL. Our software architect spent years helping that team reuse/automate/modularize their code. At a mininum, it's still just text files with syntax, despite rather different semantics.

ericmcer 6mo ago

DRY and KISS were right next to each other which I thought was funny.