15 ms·

Every time I read an article like this, "why <often cited best practice> is overrated", I think, yeah you are right in theory. But most places I have worked, th

• QuadmasterXLII 4y ago
  In my workspace, the issue isn’t that junior developers consistently DRY too much or too little, instead they make dramatic mistakes in both directions. However, the code that repeats itself unnecessarily is way, way easier to fix than the code that tangles itself up like the left pineapple example.
• davewritescode 4y ago
  Your problem isn’t DRY, your problem is that you don’t have people advocating for very basic best practices. You can’t adopt DRY or SPOT or anything else if you aren’t free to refactor and you aren’t free to refactor without some tests.
• codesnik 4y ago
  I sometimes use term "mid-level engineer syndrome", for "too many levels of abstraction in the codebase". It is very common in my experience. And untangling it's usually harder then extracting common stuff from "dumb" code. I usually don't DRY things up until three repetitions. And in test code - try to not DRY at all, copypaste is a friend of readable and mantainable specs.
  • CTmystery 4y ago
    You're almost there, IMO. This internet stranger encourages you to ditch the rule of DRYing based on the number of repetitions at all, and instead think of DRYing based on what deserves to change to together. Sometimes a single repetition in code deserves to be DRY. Sometimes 10 repetitions don't deserve to be DRY.
    • ryathal 4y ago
      Isn't that playing a little loose with definitions? if you have 10 "repetitions" that don't need to change simultaneously they aren't really repetitions in the first place. Just because a dumb analyzer says you have a 10 line block of identical code in 10 places doesn't mean it's actually identical.
      • sirmarksalot 4y ago
        You're restating the article's point. Naive DRY says make the dumb analyzer happy by abstracting out the coincidental similarities. If you work in a place that recognizes that this can be a red herring, then great, but a lot of developers and teams don't make room for that nuance. That is what the article is arguing against.
  • deleted 4y ago
    [deleted]
  • scambier 4y ago
    I have colleagues that take DRY to an extreme when it comes to tests. There are so many levels of abstractions that it's incomprehensible. Tests should be clear and readable, you shouldn't have to dig code to understand _what_ a test is doing.
    • michaelcampbell 4y ago
      Tests in particular SHOULDN'T be DRY, IMO. They need to be very much independently modifiable quickly; they're meant to be quirky end-runs around your bespoke, artisinal architecture to get at all the interesting bits. Repetition there is fine.
• lowercased 4y ago
  > People not able to factor out functions or structure their code in a readable way. Variables are called v1, v2, v3. Unit testing seen as a waste of time. CI seen as a fun toy. They lack the experience to even notice the difference. Had a colleague work under a 'team lead'. Needed to take a form with variable amount of rows of input data - max 50 - and take data, parse it, and store it. Took 20-30 lines of code. Next day "I don't trust loops, these need to be unlooped". Really? This was all in writing and stated out loud in a meeting with witnesses, and everyone agreed. "Loops can be tricky - they don't always work like you think" (something like that). So a 30 line block of code with a loop around it became 1200+ lines with 'v1, v2, v3.... v50', with 'ifs' around each one to check if that row number was also submitted. The code to generate the form was, of course, a loop that spat out holders for 50 rows. THAT was OK, because someone else's team wrote that a while back (really??) and ... it was already done and in production. The lead could not put their stamp on it. Very very very weird. Having half a dozen other people all nod their head suggesting that a 30 line loop is fraught with danger, and the correct answer is copy/paste 50 times. Felt like gaslighting, to my recollection. Worked in same dept, just not on same project together, but enough of this was heard/pickedup across the dept. And... my colleague and I aren't there any more, and to my knowledge, that team lead is still there.
  • parsadotsh 4y ago
    This is terrifying.
  • awestroke 4y ago
    Which country was this in?
    • zasdffaa 4y ago
      Elbonia perhaps?
    • lowercased 4y ago
      US of A. FWIW this was... 2005-ish.
  • 4y ago
• kareemsabri 4y ago
  In places I've worked DRY is overused, or used poorly. I can't count the number of times you get "DRY" on a code review just cause something appears twice. It's probably because it's the easiest one to spot. > learning the acronyms like DRY, and just following them Following DRY is the hard part. As the author points out, to DRY something up you need to pick the right level of abstraction. This requires experience to do well.
  • drewcoo 4y ago
    It seems like your team should check for DRYness with a static analyzer like PMD. Your reviewers have better things to look at.
• nevinera 4y ago
  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".
• ARandumGuy 4y ago
  This article is acting like DRY means "never repeat yourself in any circumstance". And it's easy to come up with counter-examples if that's your starting point. While there are certainly some DRY proponents that treat it like that, most discussions I've seen advocating for DRY treat it as a rule of thumb. There are always exceptions, but DRY will steer you in the right direction more often then not.
• galaxyLogic 4y ago
  True b ut it's still good and fun to discuss whether the best practices could be improved even further. And usually they can because they are context-dependent. There are no absolute rules, except those imposed by the compiler.
• kevstev 4y ago
  > But if you work somewhere where they do software development on the side (science, hardware, etc..) it is the main issue I have seen this working in finance. I worked at a startup with a quant, and my job became waiting for him to go home at 6 so I could clean up his code and make it maintainable the next day. Now I don't blame him- his background was operations research and he was a professor prior, without any real software background. But, he would get legit mad at me for messing with his code. We had a really tense relationship for awhile. I would occasionally break things, but he didn't really have tests until much later, so it was hard to detect and there were often subtle side effects. But anyway, I think for awhile he thought I was just a pain in the ass, until one day about 9 months after we started the project, and he wanted to run some experiments using a specific universe of securities, and just apply a few constraints to them, and I set this up for him in about 5 lines of code, and all of a sudden, I could just see the light bulb finally turn on for him as to why I was doing all of these things. After that day we became a lot more friendly.
• theptip 4y ago
  Yep, it’s a general gripe with thought-pieces; advice is context dependent. Or, put differently, my HN motto: don’t give uni-directional advice when optimizing a U-shaped error function.
• saltsucker 4y ago
  I am a CS graduate working at a top HW company and you could not have stated it more perfectly. The code I have to work with given to me written by HW engineers is pretty brutal. Talking 1k+ lines of code with 5+ nested conditions on the reg. Ofc, no unit tests. Blows my mind.
• surement 4y ago
  > But most places I have worked, these best practices were not overused, but underused For what it's worth, 90% of the code bases I've worked on overused DRY. Two pieces of code that do the same thing but that shouldn't be coupled should be repeated, otherwise you end up with a million "if" statements for all the separate cases this code will need to handle as it grows, as well as uncertainty about whether changes will have unintended consequences.
• dkarl 4y ago
  > If you have the problem that your coworkers create unnecessary abstractions, I envy you I'm curious what languages and frameworks you work with. I suspect this is something that varies from one programming subculture to another. In my experience, the only codebases where I've consistently seen underuse of abstraction have been PHP and C, and in those cases it has been because the code was written by entrepreneurs or engineers who were not software professionals. In Java and Scala I've seen plenty of code that used too much abstraction but almost no code that used too little. In C++ and Python I've seen it go both ways. In my book, what programmers need first of all is the willingness to rewrite their code. I've been trying to hit the right balance for twenty years, but even now I frequently have to backtrack because the decision to add or not add a layer of abstraction turns out to be wrong. Biasing somebody towards or away from abstraction just changes the kinds of mistakes they make without making them better at cleaning them up.
• AnimalMuppet 4y ago
  Every best practice can be overused - used where not needed, used where it doesn't fit, used in trivial cases. And if you've got people who haven't developed sound engineering judgment yet, they'll start by not using those practices. But once you convince them that they should, they'll use them everywhere, even the wrong places. This is why best practices are needed, and why they are over-rated. Where they are used, they are often over-used.
• mmcnl 4y ago
  I half agree here. Especially in Python applications, so often you so a class that is instantiated only once. I'm not sure if this is overly usage of OOP or DRY, but defining a whole class just to be instantiated once seems like a very verbose abstraction to me. There's nothing wrong with a few functions to group code together and leave it at that.