4 ms·

There was already a backlash against DRY code occurring before "AI" assistants hit the market, sadly. It was a growing movement when I was using Twitter in 2019

by mvdtnz 3y ago

There was already a backlash against DRY code occurring before "AI" assistants hit the market, sadly. It was a growing movement when I was using Twitter in 2019-2022. Some younger developers have a very different attitude to code than what I was brought up with. They have immense disdain for the Gang of Four and their design patterns (probably without realising that their favourite frameworks are packed to the gills with these very patterns). They speak snidely about principles like DRY and especially SOLID. And on places like Twitter the more snide and contrarian you can be, the more engagement you'll get. Very disturbing stuff.

deadbabe 3y ago
DRY is mostly bad. You couple a lot of things together by making them all share the same code and then a small change to that code breaks various unrelated components.
- abathur 3y ago
  I don't think it's mostly good or mostly bad in the abstract. DRYing code repeated for the same reason is mostly good. DRYing code coincidentally repeated for different reasons will sow code churn or inadvertent behavior shifts.
  - deadbabe 3y ago
    If the reason for DRYing up code is simply because it looks the same as some other code, that’s a bad reason.
- charles_f 3y ago
  Dry's mostly a smell test to be applied when copying stuff over, to check that you're doing that for the right reasons, rather than expediting shit.
  - osigurdson 3y ago
    For sure, there are obvious egregious examples of repeating one's self. There are also many more examples of developers programming by unexamined catch phrases.
- bobmaxup 3y ago
  ...said no one who inherited the maintenance of hundreds of thousands of lines of copy pasted code.
  - Spivak 3y ago
    God I would love that. Are you kidding? I've always hoped I'd get to inherit one. A codebase where each component "vendors" all its dependencies so you can fearlessly make changes and not affect anything else. You're describing heaven for a maintenance programmer -- I'm only looking at the codebase because there's a bug in some component, I likely even have a stack trace. If can just read what that bit of code does top to bottom, fix the error in just that component, write a test and ship I'll send the original author chocolates.
    - bobmaxup 3y ago
      It is hard to know if you have fixed or broke something when there are hundreds of distinct variants of it and no way to test its correctness. Also, not all maintenance involves correcting inborn defects.
    - durumu 3y ago
      Sure, that would fix the bug immediately in front of you, but what if the same bug exists in several of the other copies of the dependency? Are you going to be able to track all of the occurrences down? I think that's the big tradeoff.
      - Spivak 3y ago
        I'll take that every time, to zeroth order if the bug occurs other places it's free to err other places and I'll deal with it. But if it doesn't then does it matter? If we're experiencing a bug in a specific code-path is the right move to make a change that fixes it in one codepath but potentially changes the currently working n other codepaths that depend on it? If it weren't DRY'd would you bother changing the others? Probably not. To first order :vimgrep is totally mechanical and brain-off repeat fix is super easy.
- deleted 3y ago
  [deleted]
- caesil 3y ago
  It also frequently leads people to violate YAGNI
Kiro 3y ago
Yeah, like this dude: https://twitter.com/ID_AA_Carmack/status/753745532619665408 https://twitter.com/ID_AA_Carmack/status/753745532619665408
- mvdtnz 3y ago
  "DRY isn't absolute" is not what I was talking about. No serious developer considers any principle "absolute".
  - vasco 3y ago
    Only a sith deals in absolutes.
    - ukuina 3y ago
      Don't try it, he has the high ground.
  - osigurdson 3y ago
    I think of SOLID and DRY as primarily tools used back in the day by Uncle Bob et all to sell books and event tickets.
osigurdson 3y ago
I'm not a younger developer but I also speak snidely about SOLID and DRY. I also care a lot about code quality.
- geitir 3y ago
  No opinion on SOLID with regard to your comment. But DRY is foundational to any code because it forces you to find the right abstraction.
  - osigurdson 3y ago
    If code is copied and pasted everywhere that is obviously bad. However, some repeated code is better than none in many cases.
  - bootsmann 3y ago
    This is the kind of thinking that leads to unmaintainable AbstractFactoriesFactory classes. Sometimes allowing repeat code is good because two functions might drift away from common functionality in the future which would require a major rework of whatever abstraction you put over them to get them under the same roof.
    - osigurdson 3y ago
      Even in simpler cases it can be problematic. For example, refactoring a tiny bit of repetitive code into a separate function might seem like a good idea. But, over time, things diverge and now additional parameters and branches have to be introduced to support. A small amount of repeated code is optimal.
  - padjo 3y ago
    No, it just forces you to find an abstraction, not necessarily a good one. Badly designed abstractions can be far worse than repetition.
tester756 3y ago
Maybe because SOLID is overrated / overhyped marketing term which somehow made it to academy despite being far from actual computer science / software engineering fundamentals? We just cant stand acting as if that random list of principles created by Java's OOP mind was some source of truth for software modeling. We're just tired of seeing bilionth discussion about how to understand SOLID You probably don't see people arguing against CAP theorem because it is not some arbitrary collection of ideas (not even fully authored by SOLID author) which composes fancy mnemonic >There was already a backlash against DRY code occurring before "AI" assistants hit the market, sadly. As everything else - DRY can be abused too and people backlash against acting as those things were flawless when they arent.
Chris_Newton 3y ago
I’ve noticed similar trends. After a while, I started to realise that a lot of the critics don’t really understand the principle they’re criticising. For example, take DRY. The important principle was never really about repeating code. It was about repeating ideas. For any given concept in your system, ideally there should be a single source of truth, and therefore a single place you need to understand or change if you’re working with that concept. It’s true that this means copying and pasting non-trivial amounts of code instead of creating a meaningful abstraction is often a bad idea. But it is also a warning that any time you do repeat an idea, you now have an ongoing liability because you need to keep those different representations in sync. That could refer to database migrations that define your schema and separate ORM class definitions, or an API you define in your back-end code and a client for that API you define in your front-end code, or a retained mode UI where you have a current value in some form field that corresponds to a specific value in your internal application state, or some invariant in your data model that can be represented in both types and unit tests. People who object to combining duplicate or near-duplicate code that represents different ideas but happens to have a similar implementation at the time, on the basis that it’s a maintenance hazard for later on, aren’t wrong. They’re just objecting to a straw man that was never really the point of DRY in the first place, but has been treated as if it were due to some kind of cargo cult/gaslighting effect. The question I have now is where and when in our industry do we expect new developers to learn these principles so they do understand them properly? Some people have a formal background in CS or the like, but not everyone does, and in any case it’s not necessarily the role of an academic CS course to teach a lot of practical software development skills. I had a discussion the other day about how when I was starting out, the senior developers would give real, substantial training to the juniors to help us learn and understand these principles, but with the job-hopping culture today and the resulting general aversion to hiring juniors as a long-term investment, that just doesn’t seem to happen much any more. There are formal courses that cost a lot by personal standards but almost nothing by business standards, but there must be a tiny proportion of new developers who actually get sent on them by their employers. There are a few books worth reading, but what 20-something in 2024 wants to deal with presentation as antiquated as ink on sliced bits of tree? I suspect a lot of what today’s up and coming developers learn about these ideas comes from sources like blogs and YouTube videos, where again there is some great material out there, but as ever the problem is finding it among all the poorly understood and dubiously presented dross. And then we wonder why tools come along that seem like magic, producing a dozen lines of code in a heartbeat that seem to mostly work, and young developers think they’re great even while having little idea of all the deeper things that may be wrong with that code. It’s not really surprising, and I’m not sure it’s really anyone’s fault, but it’s definitely a problem and I wish I knew what we should do about it.
Mawr 3y ago
The backlash isn't against proper DRY (concerned with single source of truth) but fake DRY (concerned with syntactically-similiar code). Immense disdain does accurately describe how I feel towards whatever it is happens in corporate codebases. No, creating layers upon layers of indirection via classes is not ok, no matter what your SOLID guru tells you. Best practices, DRY, and SOLID are just excuses.

by mvdtnz 3y ago

deadbabe 3y ago

DRY is mostly bad. You couple a lot of things together by making them all share the same code and then a small change to that code breaks various unrelated components.

abathur 3y ago
I don't think it's mostly good or mostly bad in the abstract. DRYing code repeated for the same reason is mostly good. DRYing code coincidentally repeated for different reasons will sow code churn or inadvertent behavior shifts.
- deadbabe 3y ago
  If the reason for DRYing up code is simply because it looks the same as some other code, that’s a bad reason.
charles_f 3y ago
Dry's mostly a smell test to be applied when copying stuff over, to check that you're doing that for the right reasons, rather than expediting shit.
- osigurdson 3y ago
  For sure, there are obvious egregious examples of repeating one's self. There are also many more examples of developers programming by unexamined catch phrases.
bobmaxup 3y ago
...said no one who inherited the maintenance of hundreds of thousands of lines of copy pasted code.
- Spivak 3y ago
  God I would love that. Are you kidding? I've always hoped I'd get to inherit one. A codebase where each component "vendors" all its dependencies so you can fearlessly make changes and not affect anything else. You're describing heaven for a maintenance programmer -- I'm only looking at the codebase because there's a bug in some component, I likely even have a stack trace. If can just read what that bit of code does top to bottom, fix the error in just that component, write a test and ship I'll send the original author chocolates.
  - bobmaxup 3y ago
    It is hard to know if you have fixed or broke something when there are hundreds of distinct variants of it and no way to test its correctness. Also, not all maintenance involves correcting inborn defects.
  - durumu 3y ago
    Sure, that would fix the bug immediately in front of you, but what if the same bug exists in several of the other copies of the dependency? Are you going to be able to track all of the occurrences down? I think that's the big tradeoff.
    - Spivak 3y ago
      I'll take that every time, to zeroth order if the bug occurs other places it's free to err other places and I'll deal with it. But if it doesn't then does it matter? If we're experiencing a bug in a specific code-path is the right move to make a change that fixes it in one codepath but potentially changes the currently working n other codepaths that depend on it? If it weren't DRY'd would you bother changing the others? Probably not. To first order :vimgrep is totally mechanical and brain-off repeat fix is super easy.
deleted 3y ago
[deleted]
caesil 3y ago
It also frequently leads people to violate YAGNI

Kiro 3y ago

Yeah, like this dude: https://twitter.com/ID_AA_Carmack/status/753745532619665408 https://twitter.com/ID_AA_Carmack/status/753745532619665408

mvdtnz 3y ago
"DRY isn't absolute" is not what I was talking about. No serious developer considers any principle "absolute".
- vasco 3y ago
  Only a sith deals in absolutes.
  - ukuina 3y ago
    Don't try it, he has the high ground.
- osigurdson 3y ago
  I think of SOLID and DRY as primarily tools used back in the day by Uncle Bob et all to sell books and event tickets.

osigurdson 3y ago

I'm not a younger developer but I also speak snidely about SOLID and DRY. I also care a lot about code quality.

geitir 3y ago
No opinion on SOLID with regard to your comment. But DRY is foundational to any code because it forces you to find the right abstraction.
- osigurdson 3y ago
  If code is copied and pasted everywhere that is obviously bad. However, some repeated code is better than none in many cases.
- bootsmann 3y ago
  This is the kind of thinking that leads to unmaintainable AbstractFactoriesFactory classes. Sometimes allowing repeat code is good because two functions might drift away from common functionality in the future which would require a major rework of whatever abstraction you put over them to get them under the same roof.
  - osigurdson 3y ago
    Even in simpler cases it can be problematic. For example, refactoring a tiny bit of repetitive code into a separate function might seem like a good idea. But, over time, things diverge and now additional parameters and branches have to be introduced to support. A small amount of repeated code is optimal.
- padjo 3y ago
  No, it just forces you to find an abstraction, not necessarily a good one. Badly designed abstractions can be far worse than repetition.

tester756 3y ago

Maybe because SOLID is overrated / overhyped marketing term which somehow made it to academy despite being far from actual computer science / software engineering fundamentals? We just cant stand acting as if that random list of principles created by Java's OOP mind was some source of truth for software modeling. We're just tired of seeing bilionth discussion about how to understand SOLID You probably don't see people arguing against CAP theorem because it is not some arbitrary collection of ideas (not even fully authored by SOLID author) which composes fancy mnemonic >There was already a backlash against DRY code occurring before "AI" assistants hit the market, sadly. As everything else - DRY can be abused too and people backlash against acting as those things were flawless when they arent.

Chris_Newton 3y ago

I’ve noticed similar trends. After a while, I started to realise that a lot of the critics don’t really understand the principle they’re criticising. For example, take DRY. The important principle was never really about repeating code. It was about repeating ideas. For any given concept in your system, ideally there should be a single source of truth, and therefore a single place you need to understand or change if you’re working with that concept. It’s true that this means copying and pasting non-trivial amounts of code instead of creating a meaningful abstraction is often a bad idea. But it is also a warning that any time you do repeat an idea, you now have an ongoing liability because you need to keep those different representations in sync. That could refer to database migrations that define your schema and separate ORM class definitions, or an API you define in your back-end code and a client for that API you define in your front-end code, or a retained mode UI where you have a current value in some form field that corresponds to a specific value in your internal application state, or some invariant in your data model that can be represented in both types and unit tests. People who object to combining duplicate or near-duplicate code that represents different ideas but happens to have a similar implementation at the time, on the basis that it’s a maintenance hazard for later on, aren’t wrong. They’re just objecting to a straw man that was never really the point of DRY in the first place, but has been treated as if it were due to some kind of cargo cult/gaslighting effect. The question I have now is where and when in our industry do we expect new developers to learn these principles so they do understand them properly? Some people have a formal background in CS or the like, but not everyone does, and in any case it’s not necessarily the role of an academic CS course to teach a lot of practical software development skills. I had a discussion the other day about how when I was starting out, the senior developers would give real, substantial training to the juniors to help us learn and understand these principles, but with the job-hopping culture today and the resulting general aversion to hiring juniors as a long-term investment, that just doesn’t seem to happen much any more. There are formal courses that cost a lot by personal standards but almost nothing by business standards, but there must be a tiny proportion of new developers who actually get sent on them by their employers. There are a few books worth reading, but what 20-something in 2024 wants to deal with presentation as antiquated as ink on sliced bits of tree? I suspect a lot of what today’s up and coming developers learn about these ideas comes from sources like blogs and YouTube videos, where again there is some great material out there, but as ever the problem is finding it among all the poorly understood and dubiously presented dross. And then we wonder why tools come along that seem like magic, producing a dozen lines of code in a heartbeat that seem to mostly work, and young developers think they’re great even while having little idea of all the deeper things that may be wrong with that code. It’s not really surprising, and I’m not sure it’s really anyone’s fault, but it’s definitely a problem and I wish I knew what we should do about it.

Mawr 3y ago

The backlash isn't against proper DRY (concerned with single source of truth) but fake DRY (concerned with syntactically-similiar code). Immense disdain does accurately describe how I feel towards whatever it is happens in corporate codebases. No, creating layers upon layers of indirection via classes is not ok, no matter what your SOLID guru tells you. Best practices, DRY, and SOLID are just excuses.