4 ms·

I used to think that if something is done twice, it should be abstracted. Now, I'm a bit more careful. There's a pretty famous quote by Sandi Mentz: "Duplicati

I used to think that if something is done twice, it should be abstracted. Now, I'm a bit more careful. There's a pretty famous quote by Sandi Mentz: "Duplication is far cheaper than the wrong abstraction." https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstraction https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstracti... Make sure that you're picking the write way to think about the task at hand, rather than blindly following DRY. There are times when even a single instance of a code call would be made clearer with abstraction, and there are times where having the same piece of code duplicated multiple times (or duplicated with one piece changed) is far clearer than trying to abstract it. This Reddit Comment also has an interesting take: https://www.reddit.com/r/programming/comments/5txp5t/duplication_is_far_cheaper_than_the_wrong/ddq5ykf https://www.reddit.com/r/programming/comments/5txp5t/duplica... > The main purpose of abstractions is not to remove or reduce duplication, and not even to make code "reusable"; it is to make semantic patterns and assumptions explicit and, if possible, first-class. The further comments provide more discussion. --- I agree with the rest of your comment that refactoring and code-cleanup should be done in pieces and that, as with everything, striking the right balance is key.

cjfd 7y ago
If there is any article that I absolutely hate it is 'Duplication is far cheaper than the wrong abstraction'. A somewhat minimal abstraction has very little chance of being wrong. And if it is wrong, is it really that difficult to know? It has a chance of needing some improvement, but what code does not have a chance of needing some improvement? If one goes the full monty and introduces three design patterns every time that two lines are duplicated sometimes one will certainly end up with, perhaps, not so much the wrong abstraction as an overly convoluted one. This acticle is the excuse for programmers everywhere not to fix their messes. It is 100% opposite to what programmers need to hear.
- mcphage 7y ago
  > It is 100% opposite to what programmers need to hear. Maybe you know very different programmers than I have known, but if I had to compare what has been a bigger source of problems—missed abstractions, or abstractions that make things more difficult for no benefit, it's definitely bad abstractions almost every time.
  - cjfd 7y ago
    Well, I worked for quite some time in a code base that was basically one big ball of missed abstractions. Maybe I was traumatized a bit by that. I also have seen wrong abstractions, but not because there should not be an abstraction. If people had actually written abstractions that removed duplication instead of the ones that they half-understood from the design pattern book, they would have had come up with better ones. Duplication is in fact the best way to find the correct abstraction. The article makes this sound suspect but it really is not. The whole literature of design patterns is basically unneeded. If one just follows the path of deduplication one will discover all of them one by one and one will have applied the right one in the right place. Maybe there is some value in noticing that one still has to keep thinking and keep an eye on the likely future and not blindly do this but that is no more than a small footnote to the main message which is that you will find all the right abstractions by removing duplication. It is quite right that in TDD the refactor step is often described as the removal of duplication.
    - AstralStorm 7y ago
      You have not worked on bad enough code base. Duplication is a problem as the different implementations inevitably drift and get repeated bugs, but simple reduplication results in the rather known problem of RavioliCode() of thousands low cohesion functions. Which ends up unreadable thus bug prone and slow to develop. Use of the right patterns or rather paradigms reduces amount of code in general, thus reducing duplication. Wrong patterns are hard to actually change especially on change averse projects. The more widely used the wrong design is, the harder it is to change as the hacks on it multiply. Even worse if the wrong patterns (not code) are duplicated. These require in depth rewrites to which bosses are usually allergic, which are very hard to pull off on bigger teams too. Incredibly hard to coordinate. -- () https://wiki.c2.com/?RavioliCode https://wiki.c2.com/?RavioliCode - can happen in functional and structural code too.
      - cjfd 7y ago
        'You have not worked on bad enough code base.' You know, it is a bit pretentious to read a few sentences that someone wrote and then conclude a lot about what they know or do not know. And I actually do know what ravioli code is. I think ravioli code is mostly a good thing. Also the people on the c2.com page are not uniformly negative about it. Not all code should be ravioli code but in a project with complex requirements there should be quite a bit of ravioli code. It is true that ravioli code is not easy to understand if you are a newcomer to a project but really if the context is 'a project with complex requirements' why would anyone think that it is easy to get into, no matter how it is written? Another thing is that ravioli code absolutely needs automated tests. 'This style maximizes maintainability by old hands at the expense of comprehensibility by newcomers.' Maintainability is exactly what I want maximized. It sounds a bit bad if there are no developers that are there for a long time. But in that case you are cooked anyway, I would say.

cjfd 7y ago

If there is any article that I absolutely hate it is 'Duplication is far cheaper than the wrong abstraction'. A somewhat minimal abstraction has very little chance of being wrong. And if it is wrong, is it really that difficult to know? It has a chance of needing some improvement, but what code does not have a chance of needing some improvement? If one goes the full monty and introduces three design patterns every time that two lines are duplicated sometimes one will certainly end up with, perhaps, not so much the wrong abstraction as an overly convoluted one. This acticle is the excuse for programmers everywhere not to fix their messes. It is 100% opposite to what programmers need to hear.

mcphage 7y ago
> It is 100% opposite to what programmers need to hear. Maybe you know very different programmers than I have known, but if I had to compare what has been a bigger source of problems—missed abstractions, or abstractions that make things more difficult for no benefit, it's definitely bad abstractions almost every time.
- cjfd 7y ago
  Well, I worked for quite some time in a code base that was basically one big ball of missed abstractions. Maybe I was traumatized a bit by that. I also have seen wrong abstractions, but not because there should not be an abstraction. If people had actually written abstractions that removed duplication instead of the ones that they half-understood from the design pattern book, they would have had come up with better ones. Duplication is in fact the best way to find the correct abstraction. The article makes this sound suspect but it really is not. The whole literature of design patterns is basically unneeded. If one just follows the path of deduplication one will discover all of them one by one and one will have applied the right one in the right place. Maybe there is some value in noticing that one still has to keep thinking and keep an eye on the likely future and not blindly do this but that is no more than a small footnote to the main message which is that you will find all the right abstractions by removing duplication. It is quite right that in TDD the refactor step is often described as the removal of duplication.
  - AstralStorm 7y ago
    You have not worked on bad enough code base. Duplication is a problem as the different implementations inevitably drift and get repeated bugs, but simple reduplication results in the rather known problem of RavioliCode() of thousands low cohesion functions. Which ends up unreadable thus bug prone and slow to develop. Use of the right patterns or rather paradigms reduces amount of code in general, thus reducing duplication. Wrong patterns are hard to actually change especially on change averse projects. The more widely used the wrong design is, the harder it is to change as the hacks on it multiply. Even worse if the wrong patterns (not code) are duplicated. These require in depth rewrites to which bosses are usually allergic, which are very hard to pull off on bigger teams too. Incredibly hard to coordinate. -- () https://wiki.c2.com/?RavioliCode https://wiki.c2.com/?RavioliCode - can happen in functional and structural code too.
    - cjfd 7y ago
      'You have not worked on bad enough code base.' You know, it is a bit pretentious to read a few sentences that someone wrote and then conclude a lot about what they know or do not know. And I actually do know what ravioli code is. I think ravioli code is mostly a good thing. Also the people on the c2.com page are not uniformly negative about it. Not all code should be ravioli code but in a project with complex requirements there should be quite a bit of ravioli code. It is true that ravioli code is not easy to understand if you are a newcomer to a project but really if the context is 'a project with complex requirements' why would anyone think that it is easy to get into, no matter how it is written? Another thing is that ravioli code absolutely needs automated tests. 'This style maximizes maintainability by old hands at the expense of comprehensibility by newcomers.' Maintainability is exactly what I want maximized. It sounds a bit bad if there are no developers that are there for a long time. But in that case you are cooked anyway, I would say.