Why do so many developers get DRY wrong?

https://changelog.com/posts/why-do-so-many-developers-get-dry-wrong

by jerodsanto • 6 years ago

137 150 6 years ago

changelog.com

AdriaanvRossum• 6 years ago

Like DRY is wrong? I don't really get the point of this article.

aphextron• 6 years ago

Like DRY is wrong? I don't really get the point of this article.

More that it's a guideline, not a law. We should always use best judgement to decide when the tradeoff of readability and declarative code is worth a small amount of repetition, rather than religiously refactoring something for the sake of it.

pkaye• 6 years ago

Sometimes "A little copying is better than a little dependency."

Quekid5• 6 years ago

I absolutely subscribe to that, but then again, I don't have a Rule of Three or similar...

It's a bit difficult to get across in text, but the minimum number of repetitions of a piece of code to make it "worth" putting it in a function is... 1. (According to me, and Tony van Eerd of Postmodern C++ fame. I had come to this conclusion on my own, but his talk really articulated it well.)

It's all about limiting the scope of side-effects, accidental reuse or variables, etc. etc. such that a human can do chunking to understand the whole.

I generally find that this is not an easy thing to capture in "metrics" or "rules". Guidelines with reasonable rationales, etc. etc. and when-not-to's, definitely, but that's a really hard thing to do and it doesn't get many clicks.

EDIT: ... and just to get back to DRY. The acronym is far too absolutist, but Try-Not-To-Repeat-Yourself-Too-Much-Unless-You-Have-Good-Reason-To isn't quite as catchy, is it?

wrmsr• 6 years ago

I've seen so many times people going all in on DRY not understanding that just as dangerous as duplication is _coupling_ - the inevitable result being some ungodly $COMPANY_NAME_common lib with a thousand dependencies, and usually only depped in a codebase for a config parser and a string helper. See also node_modules and left-pad.io.

brentjanderson• 6 years ago

DRY was introduced in the Pragmatic Programmer, and Dave Thomas pointed out in a recent Changelog episode that DRY doesn't mean "Don't repeat code", it means "Don't repeat knowledge."

One concrete example: If your software has to create really complex objects, would you rather describe _how_ to create those objects in 10 places or one place? That's a scenario where you don't want to repeat yourself.

Dan Abramov [wrote about](https://overreacted.io/goodbye-clean-code/) this (linked in the OP), but in his example he's removing repetitive code. He's not removing multiple copies of the _knowledge_ about what the program is supposed to do.

It's a subtle difference that seems more difficult to describe than I'd like, but it's an important one.

crispinb4• 6 years ago

No, they're not saying it's wrong, but rather it's commonly misunderstood. From the motto alone you might think the point is to abjure all code duplication. But Hunt & Thomas' intent was instead to warn against duplicating sources of truth/knowledge - that is, all knowledge embedded in your code needs to have a canonical source, and all other references should derive from that source or you risk divergence (or in the best case must always remember to make necessary changes in multiple places).

So for example, documentation (truths about the code) should derive from the code (eg by doc generation). Otherwise the docs & code will drift apart. Or if you're passing domain information across the wire between client & server, you should derive the data structures at both ends from a common source.

iSnow• 6 years ago

all knowledge embedded in your code needs to have a canonical source

I don't get it. Code /IS/ knowledge and whenever I copy-paste code around, I duplicate not only code but also knowledge.

mrkeen• 6 years ago

The comment that it's about knowledge, not code resonated with me.

Like, if you saw Http.getClient(...).doGetRequest(...) a few times, it wouldn't be worth pulling them out into a myGetRequest(...) method. Your teammates already understand the existing, repeated statements, but they haven't seen myGetRequest(...) before, so you wouldn't be making the code any more readable to them.

But if you had Http.getClient("auth.myservice.com:8443").doGetRequest(...) in a few places, then I would pull out the host and port (or maybe the whole line), since it contains knowledge of where/how to authenticate.

Coming from the other direction: if I were reading the code, I can imagine myself looking for the one place where the auth happens, but I can't imagine myself needing to know the one place where Get requests happen (even if the 'Get' code is repeated much more than the 'auth' code)

masswerk• 6 years ago

I think, you are making a good point for what may be called mutable knowledge. I.e., when writing a shell script to iterate over a few files, nothing of this is of utter importance, since the script is meant to be run only once, thus we may consider any knowledge immutable. Also, maintenance and readability aren't much of a consideration here. In the case of a "real" application, when connecting to an endpoint, as in your example, we may consider address and credentials subject to change, so this is mutable knowledge, which ought to be represented once. However, the method of connecting is hard coded in several places, so it's pretty much immutable. If we expect the method of connecting (http) subject to change, we should consider to put this in a single spot, as well, even, if this may mean that the code may be harder to follow, since we introduced another layer of abstraction. And so on…

keeganjw• 6 years ago

I feel like this article ended before it should have. I'm still not exactly sure what the author means by Don't Repeat Knowledge. Should we not be refactoring or... just don't go overboard?

krisroadruck• 6 years ago

Hah I'm glad I'm not the only one. I finished reading it and thought that it felt like an intro and they entirely left out the meat of the article. Thought maybe it was just a lack of related knowledge as I just dabble in coding but yeah I figured at some point they would define what it was actually supposed to mean in depth. When that didn't happen I was left wondering what the point of the article was.

daxfohl• 6 years ago

They probably tried to add more info but couldn't do so without repeating some knowledge.

mntmoss• 6 years ago

When you refactor you are taking shots at moving around where coupling occurs. If your code is maximally decoupled it is primitive copy-paste code that never calls functions and intoduces unique variables for each section - and if it's maximally coupled it will look like swiss cheese, trying to reuse the same functionality for everything with clever parameterization, recursion, indirection and globals. Intentionally coupled code is most common in memory-starved environments since implict dependency helps reduce data overheads.

And so "DRY", to the extent that it's useful, encourages you to find slack areas in the code where there's low potential for introducing coupling, and to factor those out so that you have code that is mostly-decoupled without also being redundant and hard to modify - the factoring reflects "knowledge" about the problem. And yet it's not always obvious when you have the knowledge or not. Sometimes redundant-looking code is a form of hardcoded data and a factoring would only push it towards being fully data-driven(which exacts a price in debugging). The Rule of Three is just a common way of making this decision about knowledge.

novembermike• 6 years ago

The issue is that "DRY" isn't actually about coupling at all, it's about creating unambiguous ways to do things. If you have a single http library that's DRY, but if you've got a function that encapsulates several tangentially related bits of code that's not DRY. The acronym just doesn't say what it means.

temac2• 6 years ago

If your textual copy past includes some requirements of conforming to a contract, or simply actual copy past of "knowledge" (which can very well also be a under the form of a big textual pattern), the mere form of "primitive copy-paste code that never calls functions and intoduces unique variables for each section" does not actually reduces coupling (except MAYBE if it is expanded down to the metal, including expansion of syscall and/or low level libraries, but you won't do that).

Also what have globals anything to do with that, and why do you put them in the supposedly factorized code. You are mistaking it with a bad mess you once saw, maybe? On the other hand, code bases obtained through copy paste based programming can not be considered anything else than a bad mess.

But yes, factorizing can be done badly, even to the point of being counterproductive. Like anything.

crispinb4• 6 years ago

I'm still not exactly sure what the author means by Don't Repeat Knowledge

I think they're assuming that everyone has read The Pragmatic Programmer. To quote the original DRY principle from there:

Every piece of knowledge must have a single, unambiguous, authoritative representation within the system

Note that this has only an accidental relationship with code duplication, and in some cases could increase the latter.

rileymat22• 6 years ago

More often than not duplicate code is duplicate knowledge.

It often is an implicit business rule that links several statements together or a system requirement like freeing db connections and locks in the right order after use.

jschwartzi• 6 years ago

The actual problem here isn't to refactor or not refactor. The mistake a lot of developers make, including here on HN is in thinking of it mechanistically, that the code is just a bunch of operators and data and we've just gotta push it around the page some without really understanding it. That's how a lot of people interpret DRY, as an end in itself to be accomplished by pushing the symbols around and sweeping them up into something pretty.

The most important thing isn't to apply these heuristics, but to understand the problem space in which your code operates before you lay down your abstractions. That's a difficult thing to do without domain knowledge, and in a lot of enterprises you will never get access to the kind of domain knowledge you need to refactor effectively unless you're the lead or in management.

To the extent that your code is a series of statements about how the system behaves in response to a particular data input it's easy to read and documents itself. And to the extent that your data structures and statements resemble statements that a domain expert might make(move gantry 30 meters to the left, then drop the crane) they become easy to change in response to changing requirements. Domain knowledge tells you what the fixed elements of the problem space are(is it always a gantry? Does the gantry move in any directions other than left? What does it mean to drop the crane and do we do it different ways?). That informs how you structure your code and what the most clear factoring is.

It will not always be the smallest refactoring.

jmhnilbog• 6 years ago

I just wish someone would teach comp sci kids that checking for error conditions is more important than making something look pretty and/or complex.

dllthomas4• 6 years ago

Confusing knowledge for syntax leads us to both false positives and false negatives. An example of each:

In designing a web page, if you find yourself saying "there is a button here" in HTML, and in CSS, and in JS, and on the back end, that is not DRY even though the syntax looks nothing alike.

Two different APIs, for services serving different purposes controlled by different external entities, happen to have the same structure and you find that a large chunk of code can be factored out of both. I would argue that "what we currently need to do to API 1" is a separate piece of knowledge from "what ... API 2", and unifying them is not DRY.

beaker52• 6 years ago

I find DRY fascinating.

It's the source of a large portion of the accidental complexity I find in code. "If I just create this abstraction, all this duplicated code goes away" - we've all heard it and many of us have told it, but few of us realise that it's the prequel to the most popular story of all: "all this code is such a mess, there are all these extra layers that don't really make sense and unpicking it is such a pain, I can't believe someone wrote this".

The story inbetween is about a young, inexperienced developer who has 3-days to deliver the one-feature-to-rule-them-all, to appease the almighty project manager, necessitating an adventure into the labyrinth carefully crafted by the developer in the first story.

Frost1x• 6 years ago

A lot of principles like DRY (as described out of correct context in this article) have cult like followings people follow mindlessly leading to unnecessary introduced complexity.

I'm always amazed at how eager people are to over-engineer a solution that makes it a mess to deal with moving forward. Developers at large like to appear clever, tend to have (fragile) large egos, and don't seem to want to veer from established dogma--much of which based on little evidence or evidence that doesnt apply to a case they're dealing with.

dec0dedab0de• 6 years ago

It's the source of a large portion of the accidental complexity I find in code. "If I just create this abstraction, all this duplicated code goes away"

For me it's usually, "Oh crap that thing I changed I had to change here and here too, whoops its good now... Wait no I also had to change it here... and here... now that we're done with that we should be fine... DAMMIT!"

marcosdumay3• 6 years ago

The problem is that DRY is not the thing that solves this problem.

It looks like it is, you'll see plenty of people claiming it is, it may even lead people into solving the problem after they gather some experience. But it's not what solves the problem.

Buttons840• 6 years ago

DRY increases "connections" in the code (often called "coupling"). Pay attention to what you are connecting.

The dominant example of this in my mind comes from some traumatic (and dramatic) work experiences involving web scrapers.

You scrape pages A and B. Both require logins. You notice that A and B use similar code to login, so you factor it out and now you have "connected" A and B. Or, more accurately, the common "login" method is connected to A and B.

The problem is that A and B are separate ships, and they are going to different places, and you tied a rope between them. That rope is going stretch and fray and break. There's no reason logging in to A and B should be similar, it just happened to be that way at one point it time. One day, probably, those two sites change their login workflows to be completely different.

So "just repeat yourself" and let each scraper be self contained. Let each ship sail their own way, don't connect them.

One case of this isn't bad, but if your not careful you end up creating dozens of connections between things going all different directions. Break your project into "things" and graph their dependencies. If you can break X by changing Y, then X depends on Y. If you can break Y by changing X, then Y depends on X. Your dependency graph should look more like a tree than a total graph.

temac2• 6 years ago

If things needs to evolve to separate direction, you can duplicate them.

Unreasonable X is unreasonable, that's true no matter X but that's not very insightful. Unreasonable factorizing is unreasonable. So are unreasonable copy pasts.

Now a good question can be: would I "prefer" one or the other gone too far? That's merely a personal preference question, and on my side I've got a clear answer: I prefer something a little bit too abstract, to something a little bit too copy pasted. Because while abstract I still can understand more of the system more quickly, whereas duplicated I basically have to start by reading a lot more and factorizing (possibly in my head) before getting to a balanced situation...

Your own preference may vary, but I've yet to see a system maintained correctly by people copy pasting too much and not caring about anything but the one example they have to handle (because e.g. of a workflow described in a ticket).

Things can be accidentally similar, but WAY more often in copy pasted code-bases they are accidentally diverging, and that multiply the time I spend on that kind of mess by a factor that is probably near 10.

barrkel3• 6 years ago

That's right. DRY, at the limit, is compression; in some ways, it's maximally coupled, such that small changes have large effects. The quality of the abstraction is what is levered up.

agumonkey• 6 years ago

naively I'd think you can simplify them by having a single interface but with or without sharing internals (as you see fit)

but in a way that just pushes the problem to coupled interface signatures..

now I wonder, is there research in variability based interface design ? looking at systems and estimating how much some parts can change and how much are probably easy to pin down forever ?

crimsonalucard3• 6 years ago

A mutable variable causes even more "connections" as every function that touches that variable is tied to it.

If you construct your program via the point free style using function composition, the dependent function can easily be swapped out of the composition and replaced with the modified function that you need while maintaining DRY to the maximum possible effect.

You are talking about a fundamental question of program design that is largely solved by functional programming via the point free style.

It is talked about here:

https://www.quora.com/Is-senior-full-stack-engineer-Ilya-Suz...

jchook• 6 years ago

Surprised no one linked Simple Made Easy[0] yet.

Around 30 min, Rich Hickey describes how the opposite of simple is complex, and mentions the etymology, "to braid together".

"It's bad. Don't do it."

0. https://www.infoq.com/presentations/Simple-Made-Easy/

IanCal2• 6 years ago

As a counter, you have 10 scrapers with the same login code. You find one site has issues when they deploy occasionally and go and add retry logic to it, then next week find the same on another site. You go and copy paste it over all 10 or leave it. You find later the retry causes rate limiting problems so you again have to fix it in 10 places, or maybe someone fixes it in one and not the others because the implementations have drifted despite solving the same problem.

Or, you use the same code for all and if the sites change the login flow then you add a custom one for the site which is different.

Fundamentally, I don't agree with the argument that I should copy and paste code now to avoid the possibility of copying and pasting the same code later.

goto113• 6 years ago

To be fair, it is pretty easy to fork a shared component when necessary, but it is painful to maintain multiple components with duplicate logic. So it is reasonable to err on the side of DRY when in doubt.

jfengel• 6 years ago

I hadn't heard of the Rule of Three, but it parallels my own heuristic. The first time, I write the code to do the thing I need. The second time I encounter a similar thing, if I can't find the right abstraction to unify them, I go ahead and repeat myself, writing a second, similar round of code that does what it needs.

If I encounter it a third time, then I've got enough data points to make a good guess about what the right abstraction will be. If I've done a good job so far, it shouldn't be too difficult to refactor it. (Strong, static typing helps.)

This is, of course, just a heuristic, and it's not all-or-nothing. I'll take my best guess about what the right abstraction is going to be, and I'll try to get it right the first time. The second round also presents opportunities to take two points and extrapolate a line.

It all comes down to experience: not just with the system, but with the domain that the system is about, and with the way systems change and grow. No one rule of thumb ever encapsulates all that.

AnimalMuppet2• 6 years ago

I use the same approach to automate processes. The first time, I do it manually. The second time, I still do it manually, but I think "Hey, I did this once before. This is looking like something I maybe ought to automate."

The third time I automate it. By then, I understand it well enough to have good odds on being able to do the automation successfully.

amelius• 6 years ago

How often did you automate something yet?

If it's more than three times, you ought to automate the automation!

saber62• 6 years ago

DRY like anything can be properly used or misused. For example, you can normalize a database so much that any basic query comes with a massive overhead (recursion). There is a middle ground between "religion" (pure DRY) and "chaos" (no DRY).

goto113• 6 years ago

How does normalization lead to recursion? Normalization is one point where DRY really is critical, because redundant data in a database can lead to data corruption when it get out of sync. And if the data is corrupt, your whole business is screwed.

saber62• 6 years ago

I may be mis-communicating what I am trying to say.

I once had the (mis)pleasure of dealing with some novice DBAs. There were instances in the data model where things were so recursively linked that one query would fan out to 200+ to actually return the set of meaningful data. As you might of imagined, this caused scaling issues when you started dealing with significant amount of data (hundreds of GB of data in the DB).

Eventually we brought in some pros and one of the first things they did was eliminate a number of overly recursive queries and duplicated some (not all) fields of data to speed up performance. We went from 1->200+ fanout in a typical query to 1->25-ish. The performance gains were insane.

Of course it violates the "don't repeat yourself" and to abstract linked (repetitive) data in a relational way. But sometimes this best practice can really be counter-productive in edge performance scenarios. But in general yeah, don't be repetitive, abstract your stuff, and keep it clean and easy to change globally if/when needed.

3pt14159• 6 years ago

Eh. Something I find pro devs do is just code the damn thing out quickly and wait for the right abstraction to emerge before stuffing it blindly into a function. If that means a bit of repetition, fine. If you push everything into tiny little methods or functions or abstract them into their own objects the first time you come across a couple of repeated lines of code then the clearer and better solution may not emerge as the requirements start to change. On the other hand, self documenting code is most easily done via method naming.

This type of topic is hard to talk about. It's so nuanced that saying a statement about how to do it sounds like a a gutless generality. It also depends on the programming language and lifetime of the project. I've banged out some real ugly code when servers were on fire, but it was all stuff that was destined for an early death.

networkimprov6• 6 years ago

Documenting code via single-caller functions is usually a mistake, because to everyone else who looks, the set of functions is an API.

Both internal and external APIs must be kept coherent.

Also when readers are trying to understand exactly how some function changes the system state, having to refer to numerous other functions it calls is tedious.

OJFord• 6 years ago

Documenting code via single-caller functions is usually a mistake, because to everyone else who looks, the set of functions is an API.

That's a really good way of putting it.

I try to avoid it by not writing new functions, but gladly using existing ones, in my implementation of whatever single new one.

For example if I'm writing a find_and_update_foobar function, I'll use find_foobar if it exists, and with the right signature, but I won't write it just to implement the one I actually care about; ditto update_foobar.

But, professionally I've mainly only used python; so I find it still deteriorates into a mess. (I type hint extensively, but still it only takes some missing hints, or something too loosely - or wrongly - typed.)

I haven't used rust professionally/enough/on something large enough to be sure, but my feeling is that it just having a type checker prevents so much mis-refactoring.

cma2• 6 years ago

Also when readers are trying to understand exactly how some function changes the system state, having to refer to numerous other functions it calls is tedious.

This also applies for small inlined common helper functions. If it folds two or three operations into one, but doesn't have an obvious universally recognizable name, it would often be way clearer to a reader of the code to just put the few operations in directly.

marcosdumay3• 6 years ago

Also when readers are trying to understand exactly how some function changes the system state

Yep. That's why changing system state is better kept at a minimum, and at the highest layer possible.

Most languages have a very clear public/private marker for determining what is an API and what is just there for convenience (it doesn't have to be literally public/private, for some it's scope, others just tag the names, etc). You don't need to change a code's style just because of it.

On the other hand, if the functions do not have logical and atomic meanings, they will do make your code as hard to understand as it will be to name them.

notJim• 6 years ago

This is such a good, succinct way of putting it. One of the worst code-bases I've ever had to work with was largely so because of so many single-caller functions and far too granular abstraction.

emsy2• 6 years ago

Since this comment finds a lot of agreement I'm going to play the devils advocate. Private function for the sake of documentation are fine. At least if they are all on the same level of abstraction. If you've ever worked in a team where everyone works this way you stop thinking in APIs, which can be a good thing for internal code.

BurningFrog2• 6 years ago

Documenting code via single-caller functions is usually a mistake, because to everyone else who looks, the set of functions is an API.

Not when you work on a team that does this as a practice.

Many teams don't manage to have a common code style, which is a big problem in itself.

Also when readers are trying to understand exactly how some function changes the system state, having to refer to numerous other functions it calls is tedious.

The point of breaking out the small functions is to name them so understanding the code becomes easier. This takes some skill and thought, of course, and if done thoughtlessly, it will not be good. But that's true of every practice...

hinkley5• 6 years ago

Spreading state mutation out across the system is almost always a bad idea. I would categorize that person as doing DRY badly.

Coalescing state transitions should trump decomposition. But it’s often the case that you can do both at once.

pvorb2• 6 years ago

Ideally the function's name reveals what it's doing. Only if you are tracing down a problem you are required to look into the details.

This actually helps to speed up navigating code, because parts of it get meaningful names.

dragonwriter5• 6 years ago

Documenting code via single-caller functions is usually a mistake, because to everyone else who looks, the set of functions is an API.

That's less the case if the functions are local (either not exported from the module they are included in or actually function-local, in languages supporting nested functions, to their caller.

Both internal and external APIs must be kept coherent.

If it's not external, it's not an application programming interface. And, even ignoring that, there is no definition of coherent for which that approximates truth that is inconsistent with single use functions for code clarity and organization.

Even languages that don't have mechanisms to make methods/functions truly local/private tend to have conventions for indicating functions/methods not part of the intended-as-public API of a class or module.

Also when readers are trying to understand exactly how some function changes the system state, having to refer to numerous other functions it calls is tedious.

Conversely, I find the code having functions with descriptive names helps me not have to read through a bunch of irrelevant code when I'm doing that, which helps me get to the part I need to understand whatever I'm trying to understand faster and with less distraction. Yes, if it's done badly it's problematic, but that's true of literally everything.

EDIT:

Also when readers are trying to understand exactly how some function changes the system state

Yes, if you are doing relatively unconstrained imperative code that's willy-nilly modifying state, breaking that up into functions passing mutable state around is likely to make it even more incomprehensible. Decomposing into units that are externally-pure functions (that is, while they may do local mutations, they don't modify any state received from the caller), though, is not problematic. In general, except for subsystems dedicated to managing mutable state (and where this function is kept as constrained as possible), I prefer coding in externally-pure functions in general. When you start with that and use it as a constraint on decomposition, decomposition can no longer serve to obscure state modifications. Indeed, it clarifies and more narrowly isolates them.

nnq• 6 years ago

I found some simple rules for single caller functions:

1. Use them if they take <5 parametets - no point making a function if you need to pass all the local context into it

2. Use them iff they return something that can be clearly named and have an explainable and understandable TYPE, even in dynamic langs where you don't explictly type things - if you'd end up returning a tuple of 3 arbitrary things that can't be "named as one single concept" it's a code smell

3. Kepp those functions local, maybe define them inside the calling function, at least private if they're methods, anything - if your single caller function becomes unwillingly part of an api, which can esily happen in Python with a _funk() method that users could ignore it's private, you've lost

benibela• 6 years ago

Pascal has the solution for that. Nested functions:

procedure foobar;

   procedure helper1;
   begin
   end;

   procedure helper2;
     procedure subhelper2;
     begin
     end;
   begin
   end;

   procedure helper3;
   begin
   end;

begin end;

Only the foobar function can access the helper functions.

_y5hn2• 6 years ago

What may help is pondering about object encapsulation, composition and usage patterns. Ie. either be the domain expert, or develop into one by building the domain.

In order to do this, recognize iterations are key and that code must both work today and allow for future evolution.

With clearer goals, one might save time and effort refraining from premature optimization and overzealous refactoring. When direction is unclear, you can comfortably lean on established accomplishments while avoiding regressions.

DRY and YAGNI may thus take a backseat to incrementally deductive design.

crimsonalucard3• 6 years ago

Functional programming via composition solves this problem by making your functions composable and easily decomposable. The right abstraction under this methodology is mostly correct every time and if not the abstraction is easily broken apart and recomposed with a modification due to the fact that functions can be decomposed.

papito3• 6 years ago

The rule of threes. It is VERY hard to nail an abstraction until you see slightly different implementations of it at least three times.

Also, I think we kind of said goodbye to DRY after we decided that microservices is The Way. How many microservices reinvent the same goddamn wheel?

jknoepfler• 6 years ago

Which is why we template, build dsls and generic support libraries, and generally automate the hell out of microservice boilerplate. (Usually after a lot of slogging).

hinkley5• 6 years ago

I have been experimenting with code reuse via repository forking. Not much to show for it so far, unfortunately.

tylerjwilk00• 6 years ago

So true. I'd almost consider it a kind of premature optimization.

Trying to nail down DRY abstractions not too early but not too late is often tricky but concern over it probably puts you in good company.

pvorb2• 6 years ago

One problem with code that is destined for an early death: It usually lives (much) longer than originally expected.

iovrthoughtthis• 6 years ago

I think this is a human reaction to their environment.

1. Write code 2. Cleanup the mess 3. Write more code 4. Realise there a better way. 5. Stick with it because effort to change < benefit gained.

In Refactoring Kent Beck doesn’t just show extracting variables, functions and classes but also re-inlining them.

The problem is at scale, re-inlining is hard. If it were easier to do, it might be done more.

I find that waiting for N repetitions of some abstractable code is a heuristic to mediate between the cost and benefit of refactoring.

I don’t have an answer for improving it. Perhaps making easier to automatically manipulate the code in this manner?

I’ve thought for a while that it would be interesting to treat a code base as a database. Applying documented migrations to it which describe the code transformations occurring (and how to reverse them). Then changing these aspects of code would be trivial.

But then your meta program, the set of transformations which generate your current code base, would probably suffer the same problems as your codebase.

tigershark2• 6 years ago

I instead find that when using functional languages the code begs you to go in a small, tiny function. It makes the intent much more clear about what that code is doing and 99% of the time you don’t need to know how is doing it. Obviously if that code is used only once then it doesn’t make sense to extract it, but I find out that small pure functions are really composable, powerful and reusable. Maybe the best example is the pipe operator definition in F#:

  let (|>) x f = f x

It’s extremely simple, extremely powerful and it’s used pretty much everywhere.

thdrdt2• 6 years ago

Some things overlap, but I think your comment is more about KISS. Early abstractions don't fit KISS. And I believe banging out ugly code can still fit KISS because it does the job.

DRY falls into a different category. For example if you use `.toFixed(2)` to format floats everywhere it is better to abstract it to a function. And I believe this is what the article is about.

Formatting a float is a kind of logic or knowledge about how you present values in the view. You should not repeat this knowledge because if it is later decided that the view must show 3 decimals you are in trouble.

Maybe DRY can be easily explained by: don't repeat (business) logic.

bromuro• 6 years ago

KISS?

golergka• 6 years ago

That's a good strategy – but you have to be confident enough that when the right abstraction emerges, you will be able to squeeze necessary refactoring in between of other tasks that need to be done. It's ready to do when you're a team lead or a solo developer, but when someone else has technical leadership, you won't be able to do this without their support.

aazaa• 6 years ago

This article would benefit from some code examples.

As it is, it left me with the same thought as those who claim to never need debuggers or object-oriented features: Fine let's say you're right - how do I implement your system?

crispinb4• 6 years ago

The comments here suggest two things: (1) most people misunderstand DRY (ie. they think it's about code rather than knowledge duplication), and (2)the article didn't do a great job of clearing the issue up.

Though an alternative to (1) is that the meaning of DRY in common dev parlance has changed & has come to mean something different from Thomas & Hunt's intention.

layer82• 6 years ago

What they meant by DRY is otherwise known as SPOT — Single Point Of Truth — which is harder to misinterpret. The same “truth” — which can be data, values, behavior, policy, etc. — should not be defined multiple times in separate places, because a future change would have to be applied to all the places, or else cause different parts of a program or datastore to have inconsistent views on what the “truth” is.

If you google for it, you will find the synonymous “Single Source Of Truth”, which however makes for a worse acronym.

maest• 6 years ago

Incidentally, this may explain why caching is hard - cache invalidation in particular. By definition, it must violate this SPOT/SSOT principle.

layer82• 6 years ago

While there is a thematic connection, SPOT is usually more of a design-time (or coding-time) principle. Caches still represent the same source, just time-delayed.

regularfry• 6 years ago

That's not quite true; it's closer to say that it's very easy to design a cache mechanism which accidentally violates SPOT.

rileymat22• 6 years ago

I don’t disagree with this but it is more complicated because often the order statements are executed in is knowledge. Much duplicated code is duplicated knowledge.

The question is whether it is a coincidence or the same concept.

rojobuffalo• 6 years ago

Having a couple lines that are similar or copied in several places shouldn't be considered such a bad thing. Repetition reveals similarity, and having clear signals of similarity is really important. It's often more expressive / easier to understand than a single method name.

Premature abstractions are way worse than repetition. A poor or insufficient abstraction leads to obfuscation which leads to misunderstanding which leads to novel constructs for the same responsibility. Because a poor abstraction can be really really difficult to back track, you end up with hacky work-arounds to get something done.

I think encountering novelty in a codebase is the biggest thing that damages comprehension; and repetition actually enhances comprehensibility.

lr4444lr• 6 years ago

I feel like this article is being critical about something without justly staking a clear claim about what the right approach is. In my experience, the benefit of DRY code is bug reduction and overall increased new development velocity. There is a whole class of bugs around similar behaviors that devs and product managers expect to move in sync which don't, because features develop over time and it was just easier to code separate small bits than refactor into a common code path. Yes, it can make readability harder to unify into abstractions and create the right configs or import steps. But the time hunting down and fixing the bugs, plus the drag on overall feature development due to having to write updates in multiple places and test for them is far worse to deal with for not taking that preventative measure.

proc0• 6 years ago

So what's the problem with what people do? The article doesn't go into detail. Keeping things 100% DRY is never a bad thing, with the only exception that code becomes too obscure and hard for new contributors to start on, which granted it's pretty important, however it's not like people are getting DRY wrong.

makecheck• 6 years ago

I don’t mind repeating something as long as I write it in a style that could become a function in a straightforward way. Seems like the first time you have to change something, you realize it applies to one case and not the other. The more important thing is that the repeated/common parts are obvious.

For example, if you reuse the same logic in a couple places, where the only difference is some specific variable, it should be written as a block with alias variables at the top. That way, two different cases look literally the same (except for a couple assignments at the top).

sethammons• 6 years ago

A friend at work (years ago) introduced me to WET: Write Everything Twice, a cheeky response to DRY enthusiasts. It falls just short of the Rule of Threes (as soon as you write it a third time, refactor it out).

I think this article does have something going for it. DRY should be about knowledge. Don't repeat yourself by handling tax rates all over, get that into a central place. This is not about turning similar looking blocks of code into a clean single block that handles everything as these tend to actually hurt maintainability (ever see the littering of conditionals in "DRY" code because multiple call sites use the similar code slightly different? Yeah, you did it wrong).

Another comment wrote it well by mentioning SPOT: Single Point of Truth. DRY and WET SPOTs. I feel like an analogy is forming that someone more quippy than myself can ferret out.

hinkley5• 6 years ago

DRY tests are. the. worst. Way to lock us into last years’ requirements, bud.

This is where DAMP comes in. Descriptive And Meaningful Prose.

I should be able to read the test failure message and know what I broke. Barring that, I should be able to read the test (not the whole fucking test file) and tell what I screwed up.

Anything else kills momentum, and I just want to get away from your code as fast as possible. Which means more tech debt.

stinos• 6 years ago

On the other hand, articles like this or principles like WET don't suddenly make it ok to just go ahead and duplicate code all over the place. It's not like code cannot be knowledge. Depending on the type of code SPOT and (what gets misunderstood as) DRY are totally about the same thing and mean the proper solution is to take those bits of similar code and make them into a function. Anyway, you likely know that already but I just felt information like this needs to be on this page as well to avoid possible beginners reading it might think all duplication is fine :] Because I've seen what happens when code containing the knowlegde gets duplicated and the result was never good and most of the time horrible on all fronts.

contingencies• 6 years ago

Nice one!

Added to https://github.com/globalcitizen/taoup

_bxg1• 6 years ago

The article is weirdly void of a counter-proposal, or a definition of what it means to not repeat yourself in terms of "knowledge"

reggieband• 6 years ago

I have so much to say on this topic that I feel like I can't say anything. I'll just leave it at: beginners tend to do too little, intermediates tend to do too much and experts try to do no more than enough.

WalterBright• 6 years ago

Any programming guideline regarded as Dicta Bölke is going to lead to garbage.

They always must be leavened with Good Judgement.

drewcoo• 6 years ago

Does anyone else see a certain irony in the raw number of Dry articles in existence? Or the fact that people keep writing them?

I think the deeper problem in the software industry is that we have no collective memory and need to DRY up as a whole.

fsajkdnjk• 6 years ago

nowadays, as golang dev, i don't even know how DRY looks like :D

what I've learnt throughout many years of coding is that purest mantra one should follow is YAGNI. devs think like devs and strive for perfect code. but that goes directly against the business. the majority of the entire world is being run on really bad code. but that bad code works. and that is what is important.

in a way, you should treat things like blackboxes with strict interfaces. no one should care how the box works, as long as its interface works like it is supposed to.

PS: the dangers of DRY are introduction of deep dependencies that might, and probably will, bite you in the ass along the way. DRY should be used only for libraries, not for business logic - ever.

epicgiga• 6 years ago

DRYing the code is just an entry level form of simplifying the code. It's a good starting point, but its value quickly taps out once junior devs start writing incrementByOneFromZeroToNLoop(n) functions.

Code is closer to a craft like carpentry than a pure knowledge job. There aren't any rules, only heuristics, and it takes time to hone your skills (not "learn" them).

The biggest limiter in this is the excessive tendency for flat hierarchies in dev. It flies in the face of the apprentice - journeyman - master system that has always naturally structured the delivery and learning of craftsmanship.

drbojingle• 6 years ago

Imo, Dont Repeat Yourself makes most sense when you forget about code and take it to mean that you shouldnt repeat your work.

IE, if you wrote some code in one place that you needed elsewhere, copy pasting the code is fine under my interpretation because it allows you to spent the least amount of time working on a problem you've already solved.

anonymouswacker• 6 years ago

Why do developers not see the forest for the trees?

namuol• 6 years ago

[...] the original “Don’t repeat yourself” was nothing to do with code, it was to do with knowledge
The trouble with DRY is it has no reference to the knowledge bit, which is arguably the most important part!

Okay. Now what does this mean? Is this article effectively a tantalizing recommendation to read The Pragmatic Programmer?

hyperpallium• 6 years ago

You can have specious repetition, code that is identical only by coincidence, not in a deep semantic sense.

To determine what it is, you need to understand the domain. Part of that is knowing not just what it is, but how it generalizes and predicting how it is likely to change.

Of course, this is approaching perfection. One could also cut and paste monkey-like, e.g. instead of looping (without a performance need to unroll loops).

wruza• 6 years ago

The opposite of the rule of three and pattern detection is an instant detection stupid code (no funny acronym for that). An example of stupid code:

  let setX = (e) => {this.x = +e.target.value}
  ... other setup ...
  input({onchange:setX, value:this.x})

This code is not a subject of undry or rule of three, as it’s ratio of meaning to character count is too low.

And yet some frameworks make a decision to abstract it out at a wrong point:

  let [x, setX] = ...
  ... other setup ...
  input({
    onchange:(e) => setX(+e.target.value),
    value:x})

instead of clean and readable

  input_num(this, 'x', {})
  // or
  this.input_num('x', {})

seanwilson• 6 years ago

The comments should make it painfully obvious there isn't a general rule that applies to all projects in all situation.

DRY, WET, DAMP, SPOT, KISS, YAGNI...

Software engineering is too nuanced to be summed up in an acronym and surely the inventor of each acronym only intended it to be a basic rule of thumb.

goto113• 6 years ago

"It feels good" - I think that is a really important point! Overzealous DRY'ing is like a game. Every few tokens you save by clever reuse is a small victory. So it is easy to lose sense of the big picture. Programmers often like logical games and challenges, but it is dangerous to treat development like that.

We should be weary of micro-optimizations for "elegance" which actually hurt the larger-scale maintainability of the system.

skywhopper• 6 years ago

I wish the author here or Dave Thomas would explain what they mean by DRY meaning “knowledge”. They both say that and leave it as obvious...

dllthomas4• 6 years ago

Happy to do as asked, though I am a different Dave Thomas.

Per my understanding, it's anything you might say about your system, especially as it relates to your domain.

"There is a button here", "this is what we store about users", "broken widgets are red", "this is how we calculate interest", ...

dllthomas4• 6 years ago

It's memetics.

"DRY" is catchy, easy to talk about, easily verbed as a recommendation, seems like a good idea, and seems to be recommended by people who know what they're doing.

The problem is that it seems self explanatory, so no one discusses the definition. At the same time, the more obvious definition isn't the right one.

As a counter-meme, I have been proposing we refer to overaggressive syntactic deduplication as "Huffman coding".

luord• 6 years ago

Unlike Abramov's original post, I actually agree with this one, being more nuanced. The author acknowledges that DRY (and ultimately, clean code et al) itself is not evil; it's just misunderstood.

Why do so many developers get DRY wrong?

Related Stories