Duplication Isn't Always an Anti-Pattern

I've had coworkers in the past that treat code like it needs to be compressed. Like, in the huffman coding sense. Find code that exists in two places, put it in one place, then call it from the original places. Repeat until there's no more duplication.

It results in a brittle nightmare because you can no longer change any of it, because the responsibility of the refactored functions is simply "whatever the orignal code was doing before it was de-duplicated", and don't represent anything logical.

Then, if two places that had "duplicated" code before the refactoring need to start doing different things, the common functions get new options/parameters to cover the different use cases, until those get so huge that they start needing to get broken up too, and then the process repeats until you have a zillion functions called "process_foo" and "execute_bar", and nothing makes sense any more.

I've since become allergic to any sort of refactoring that feels like this kind of compression. All code needs to justify its existence, and it has to have an obvious name. It can't just be "do this common subset of what these 2 other places need to do". It's common sense, obviously, but I still have to explain it to people in code review. The tendency to want to "compress" your code seems to be strong, especially in more junior engineers.

Yeah I have seen that too. Any it's easily sold to non-technical managers

Is there any code (yours, open open source, doesn't matter) that you would recommend as non "huffman compressed"? Give us an example of what you like.

Yup. People are taught DRY very early on, as an introductory "engineering" practice above the nuts and bolts of writing code.

But nobody really teaches the distinction between two passages that happen to have an identical implementation vs two passages that represent an identical concept, so they start aggressively DRY'ing up the former even though the practice is only really suited for the latter subset of them.

As you note, when you blindly de-duplicate code that's only identical by happenstance (which is a lot), it's only a matter of time before the concepts making them distinct in the first place start applying pressure for differentiation again and you end up with that nasty spaghetti splatter.

I would probably still be working with one of these assholes if I hadn’t gotten laid of. Dude was 40. How tf have you not learned better by now?

I like doing this for data models - but it’s easy for people to go overboard

I think grug has the best refactoring advice: https://grugbrain.dev/

> But nobody really teaches the distinction between two passages that happen to have an identical implementation vs two passages that represent an identical concept, so they start aggressively DRY'ing up the former even though the practice is only really suited for the latter subset of them.

Even identical implementations might make more sense to be duplicated when throwing in variables around organizational coupling of different business groups and their change mgmt cycle/requirements.

100% agree. I see this kind of refactoring as a form of bike-shedding. It's so _easy_ to do this, anyone can do it. It's much harder to think about and design for long-term change and maintainability. Much easier to just deduplicate and declare victory.