This is a good example of what I call Similar vs Same. "Similar" code is code that happens to look very close, but is actually addressing separate use-cases.

This is a good example of what I call Similar vs Same. "Similar" code is code that happens to look very close, but is actually addressing separate use-cases. "Same" code is code that looks close, and is addressing the same use-case. Same code is safe to unify, similar code is not. Of course, that's looks like a weak definition, because it ends up falling to, "how do you define your use-cases?" Well, that's kind of the point. The biggest thing to point out is that use-cases are not static, but change as the business changes. The second point exemplifies this: For example, we later needed many special cases and behaviors for different handles on different shapes. So now they're definitely separate use-cases, that just happen to look similar because they're achieving similar goals. But the methodology may and can be completely different depending on the circumstance. So even if this was originally same code, and the unification was successful, it would have ended up split apart again anyway. And that's OK to. Sometimes things that really are the same use-case end up splitting as the business changes or learns. We as engineers need to recognize when this happens and split out the code also, instead of creating a tangled mess of one code serving two different use-cases. EDIT: Just read some of the comments, and my thoughts expressed here are probably a subset or incomplete version of "prefer duplication over the wrong abstraction": https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction https://news.ycombinator.com/item?id=29240647 https://news.ycombinator.com/item?id=29240647