←back to thread

Duplication Isn't Always an Anti-Pattern

(medium.com)
52 points birdculture | 4 comments | 02 Dec 25 08:58 UTC | HN request time: 0.201s | source
1. lateforwork ◴[07 Dec 25 15:14 UTC] No.46182261[source]▶
If you have only one copy of the code then you only have to fix the bug in one place, as opposed to a dozen. So there is significant cost savings. But there is a problem: when you make a bug fix you have to test all the different places it is used. If you don't then you could be breaking something while fixing something. If you have comprehensive automated tests then you can have just one copy of the code--if you introduce a bug while fixing a bug the automated tests will catch it.

If you don't have comprehensive test automation then you have to consider whether you can manually test all the places it is used. If the code is used in multiple products at your company--and you aren't even familiar with some of those products then you can't manually test all the places it is used. Under such circumstances it may be preferable for each team to have duplicate copies of some code. Not ideal, but practical.

replies(2): >>46182556 #>>46182900 #
2. porridgeraisin ◴[07 Dec 25 15:48 UTC] No.46182556[source]▶
Yep. This is the actual reason behind duplication I've seen 99% of the time.
3. hinkley ◴[07 Dec 25 16:29 UTC] No.46182900[source]▶
I don’t think it’s the cost of making the same fix n times, it’s the cost of missing one, or two. Especially if customers notice first.
replies(1): >>46183261 #
4. lateforwork ◴[07 Dec 25 17:15 UTC] No.46183261[source]▶
Right, but you have to consider the cost of incorporating bug fixes without fully testing them. That too can introduce new failures that are noticed by customers first.