Comment by al_borland
1 year ago
I work with someone who has a habit of code duplication like this. Typically it’s an effort to turn around something quickly for someone who is demanding and loud. Refactoring the shared function to support the end edge case would take more time and testing, so he doesn’t do it. This is a symptom of the core problem.
I've been getting stricter about not letting that stuff into the codebase. They always say they'll clean it up later but they never do.
To paraphrase a Python saying, “master is where bad code goes to die”.
> They always say they'll clean it up later but they never do.
Are you sure there's anything needing cleaning up?
The duplicated code that needs updating in 50 places every time a bug or new feature comes in? Yes, I'm sure.
1 reply →
I have a habit of doing this for data processing code (python, polars).
For other code it's an absolute stink and i agree. But for data transforms... I've seen the alternative, a neatly abstracted in-house library of abstracted combinations of dataframe operations with different parameters and.. It's the most aesthetically pleasing unfathomable hell I've ever experienced.
So now, when munging dataframes, i will be much faster to reach for 'copy that function and modify it slightly' - maintenance headache, but at least the result is readable.
But it's a false premise; the claim is that just copy/pasting something is faster, but is it really?
The demanding / loud person can and should be ignored; as a developer, you are responsible for code quality and maintainability, not your / their manager.
I agree. I always take the time to clean things up along the way, but short term thinning is often incentivized and rewarded.
> I work with someone who has a habit of code duplication like this.
Are you sure it's code duplication?
I mean, read your own description: the new function does not need to support edge cases. Having to handle edge cases is a huge code smell, and a clear sign of premature generalization.
And you even admit the guy was more productive and added less bugs?
There is a reason why the mistakes caused by naive approaches to Don't Repeat Yourself (DRY) are corrected with Write Everything Twice (WET).
I didn’t say less bugs. There are a lot of bugs, they are just localized to each call, and then copy/pasted all over the place. So when found, they need to be fixed in a bunch of places. It makes for quite the mess.
They just aren’t making changes to the shared function, so they don’t need to test existing functionality still works, just their single use case.