4 ms·

I'm a DevOps engineer. I totally buy duplication is better than the wrong abstraction but I'd like to nuance it: duplication is better than an abstraction used

I'm a DevOps engineer. I totally buy duplication is better than the wrong abstraction but I'd like to nuance it: duplication is better than an abstraction used by two disparate parties (groups of people that don't talk to each other). This is in agreement with Conway's law, which absolutely governs everything I do. I work on a DevOps team that supports several different development teams all working on different things. The code I write for those teams I often duplicate along team boundary lines. Build scripts, for example, I write and I put them in each team's git repository. These might look very similar. This allows the scripts to grow and change and evolve according to the different teams needs without the teams needing to talk to each other. "Proper duplication" goes back to separation of concern. If you have two different concerns (using the lens of Conway's law, two very different teams) using the same code, perhaps they should not be using the same code because that is not a separation of concern. Separate the concerns by separating the code paths both concerns use. This type of duplication is praised in more depth on wingolog[1]. I highly recommend reading it as something every engineer should read. It's very important to know when to duplicate and when not to do so, because duplicating it the wrong time can lead to pain, but not duplicating can lead to pain also. 1: https://wingolog.org/archives/2015/11/09/embracing-conways-law https://wingolog.org/archives/2015/11/09/embracing-conways-l...

dahart 3y ago
This. I think you’re hitting the nail on the head. The question is whether there are multiple dependencies on a given bit of code. When there are multiple dependencies, changing the code because one of them wants something means the code needs to be checked and tested against all the other places the code is being used. And it’s really really common to have inadequate understanding and inadequate test coverage, so things break, and hence people develop superstitions about code that shouldn’t be touched. Another way of putting it is that if the code is really truly duplicated, then it doesn’t need to change at all. If it has to change, the need for change is there because the multiple parties depending on that code have slightly different needs and slightly different ideas about what they want. Abstracting the code to make deduplication happen is just a way of spackling over those differences, but it can and does often cause trouble down the road, even when it’s done well. Once abstracted for two dependencies, a third dependency or more without test coverage can make changes exponentially more dangerous and error prone. Duplication is good when forking for separate parties (or separate dependencies), each of whom may wish to customize the code, and now they are free to do so without the risk or fear of breaking someone else. I feel like the author of the article didn’t understand the benefits of duplication.
schnable 3y ago
100% agree. Coupling between systems and teams is very expensive and should be done as deliberately as possible.
waffletower 3y ago
Very sad hearing this from a DevOps engineer. While the config smear of ops is encouraged by their tools (Terrorform is a fantastic example), a DevOps engineer that does not dedicate themselves to DRY practices will erode the productivity of an organization by default. I remember how Terrable things were before our Ops team developed strong module abstractions for our infrastructure. And get them to talk to each other.
ncruces 3y ago
This is an example of Go's proverb: A little copying is better than a little dependency.

dahart 3y ago

This. I think you’re hitting the nail on the head. The question is whether there are multiple dependencies on a given bit of code. When there are multiple dependencies, changing the code because one of them wants something means the code needs to be checked and tested against all the other places the code is being used. And it’s really really common to have inadequate understanding and inadequate test coverage, so things break, and hence people develop superstitions about code that shouldn’t be touched. Another way of putting it is that if the code is really truly duplicated, then it doesn’t need to change at all. If it has to change, the need for change is there because the multiple parties depending on that code have slightly different needs and slightly different ideas about what they want. Abstracting the code to make deduplication happen is just a way of spackling over those differences, but it can and does often cause trouble down the road, even when it’s done well. Once abstracted for two dependencies, a third dependency or more without test coverage can make changes exponentially more dangerous and error prone. Duplication is good when forking for separate parties (or separate dependencies), each of whom may wish to customize the code, and now they are free to do so without the risk or fear of breaking someone else. I feel like the author of the article didn’t understand the benefits of duplication.

schnable 3y ago

100% agree. Coupling between systems and teams is very expensive and should be done as deliberately as possible.

waffletower 3y ago

Very sad hearing this from a DevOps engineer. While the config smear of ops is encouraged by their tools (Terrorform is a fantastic example), a DevOps engineer that does not dedicate themselves to DRY practices will erode the productivity of an organization by default. I remember how Terrable things were before our Ops team developed strong module abstractions for our infrastructure. And get them to talk to each other.

ncruces 3y ago

This is an example of Go's proverb: A little copying is better than a little dependency.