5 ms·

The flip side is, duplication is bad because when you find a bug and fix it, did you fix it everywhere? How many places were there where the bug needed fixed?

The flip side is, duplication is bad because when you find a bug and fix it, did you fix it everywhere? How many places were there where the bug needed fixed? Are you sure you got them all? It's much easier when there's only one place that you have to fix.

mfitton 3y ago
I'm getting shot in the foot by this right now as our team embarks on tackling some long-term tech debt. The approach we've found that works is health checks and manually looking into cases when we think we've fixed a bug, as it will often point us to a piece of duplicated code we missed that we can wrap into the fold.
postalrat 3y ago
Or maybe it's a bug in 80% of the cases and not in the other 20%.
preommr 3y ago
Ticket closed, case closed. And I am only half-joking about that. I don't think that effort is that visible and often goes unrewarded. I feel like a lot of managers don't directly, but indirectly use number of tickets closed as a sign of productivity which affects promotions and compensation. Obviously YMMV, but teams that care about their code quality to such an extent are less likely than places that act as ticket factories.
hooverd 3y ago
Maybe that bug in that abstraction was actually load bearing.
ozim 3y ago
Flip side of the flip side is bad because when you fix the bug in "abstraction" or de-duplicated piece of code: how do you know you did not break something you don't know. Duplication is easier because once you fix that single place - you are 100% sure you fixed that place and you did not break 10 other places. Maybe you know "by writing unit tests", but when you write unit tests, when you find out you broke something. Funny story time: had an add/edit popup in system because they looked the same so dev just made it "single thing". Something like 3 months dev1 fixed something -> qa2 found a bug X -> dev2 fixed something -> qa1 found a bug Y -> dev3 fixed something -> qa 3 again found bug X. When I got into code base I noticed that ping-pong because somehow I was only sane person to check git history and I split things up. Something like that happened multiple times in my career

mfitton 3y ago

I'm getting shot in the foot by this right now as our team embarks on tackling some long-term tech debt. The approach we've found that works is health checks and manually looking into cases when we think we've fixed a bug, as it will often point us to a piece of duplicated code we missed that we can wrap into the fold.

postalrat 3y ago

Or maybe it's a bug in 80% of the cases and not in the other 20%.

preommr 3y ago

Ticket closed, case closed. And I am only half-joking about that. I don't think that effort is that visible and often goes unrewarded. I feel like a lot of managers don't directly, but indirectly use number of tickets closed as a sign of productivity which affects promotions and compensation. Obviously YMMV, but teams that care about their code quality to such an extent are less likely than places that act as ticket factories.

hooverd 3y ago

Maybe that bug in that abstraction was actually load bearing.

ozim 3y ago

Flip side of the flip side is bad because when you fix the bug in "abstraction" or de-duplicated piece of code: how do you know you did not break something you don't know. Duplication is easier because once you fix that single place - you are 100% sure you fixed that place and you did not break 10 other places. Maybe you know "by writing unit tests", but when you write unit tests, when you find out you broke something. Funny story time: had an add/edit popup in system because they looked the same so dev just made it "single thing". Something like 3 months dev1 fixed something -> qa2 found a bug X -> dev2 fixed something -> qa1 found a bug Y -> dev3 fixed something -> qa 3 again found bug X. When I got into code base I noticed that ping-pong because somehow I was only sane person to check git history and I split things up. Something like that happened multiple times in my career