4 ms·

I would argue copy/pasted code is usually not technical debt because it's very isolated and easy to change, and it's cheap to consolidate it later. Crappy abstr

I would argue copy/pasted code is usually not technical debt because it's very isolated and easy to change, and it's cheap to consolidate it later. Crappy abstractions are a way bigger source of technical debt than repeating yourself IME. It's a lot easier to create a new abstraction than modify an existing one, so you generally want to wait as long as possible.

SkyPuncher 6y ago
A single copy and paste isn't likely an issue. I've worked in code bases where that pattern ends up happening in dozens or hundreds of places - all with slightly different style/layouts. It becomes a night mare to change anything consistently across the code base because it's done differently in every place.
Jtsummers 6y ago
Copy/pasted code becomes technical debt at scale, especially if there's an unknown error in the original. Now you have 10s or 100s of variants out there, each individually tweaked and so not readily identifiable as true copy/paste repetition, all containing some variant of this subtle bug. You find out about for interface A, and fix interface A. Maybe you remember that B-C were copy/pasted versions of A and check them out and correct it there. But D-Z were all copies made by others, following your example, and you miss them. It's not scalable, and produces severe consequences when used without care (which is most of the time, it seems).
- glintik 6y ago
  Copy-paste is not a tech debt, but just bad practice. Bad practices can increase tech debt.
deleted 6y ago
[deleted]
ptero 6y ago
I think you are being downvoted for the first part of your first sentence, with which I also somewhat disagree: copy/paste usually creates technical debt and even though each pair is easy to fix, with time they almost always diverge and are forgotten about. Which is bad. But I strongly agree with your second part: bad abstractions are a much bigger source of technical debt. Abstractions that do not match the problem lead to convoluted solutions, reduced functionality and are very hard to break out of with incremental fixes.
- bananaface 6y ago
  I think that's why I'm being downvoted too, but frankly if the codebase is so bad that something is being copy/pasted hundreds of times to the point of unmaintainability, the abstractions that same team would build would probably also be disastrous, and much harder to deal with. Is that preferable? But tbh, I'm skeptical of the premise to begin with. It's still easier to gradually consolidate 100 slightly different uses of a pattern than blindly create an abstraction that adequately covers those 100 uses. If your team is useless, it's better that their code be fragmented and atomic anyway, because big mistakes are inevitable. You don't want to make it hard to touch those mistakes. You want that code to be uncoupled & disposable. But at that point the argument is getting pretty abstract. Depends on the specific codebase.

SkyPuncher 6y ago

A single copy and paste isn't likely an issue. I've worked in code bases where that pattern ends up happening in dozens or hundreds of places - all with slightly different style/layouts. It becomes a night mare to change anything consistently across the code base because it's done differently in every place.

Jtsummers 6y ago

Copy/pasted code becomes technical debt at scale, especially if there's an unknown error in the original. Now you have 10s or 100s of variants out there, each individually tweaked and so not readily identifiable as true copy/paste repetition, all containing some variant of this subtle bug. You find out about for interface A, and fix interface A. Maybe you remember that B-C were copy/pasted versions of A and check them out and correct it there. But D-Z were all copies made by others, following your example, and you miss them. It's not scalable, and produces severe consequences when used without care (which is most of the time, it seems).

glintik 6y ago
Copy-paste is not a tech debt, but just bad practice. Bad practices can increase tech debt.

deleted 6y ago

[deleted]

ptero 6y ago

I think you are being downvoted for the first part of your first sentence, with which I also somewhat disagree: copy/paste usually creates technical debt and even though each pair is easy to fix, with time they almost always diverge and are forgotten about. Which is bad. But I strongly agree with your second part: bad abstractions are a much bigger source of technical debt. Abstractions that do not match the problem lead to convoluted solutions, reduced functionality and are very hard to break out of with incremental fixes.

bananaface 6y ago
I think that's why I'm being downvoted too, but frankly if the codebase is so bad that something is being copy/pasted hundreds of times to the point of unmaintainability, the abstractions that same team would build would probably also be disastrous, and much harder to deal with. Is that preferable? But tbh, I'm skeptical of the premise to begin with. It's still easier to gradually consolidate 100 slightly different uses of a pattern than blindly create an abstraction that adequately covers those 100 uses. If your team is useless, it's better that their code be fragmented and atomic anyway, because big mistakes are inevitable. You don't want to make it hard to touch those mistakes. You want that code to be uncoupled & disposable. But at that point the argument is getting pretty abstract. Depends on the specific codebase.