The Wrong Abstraction (2016)
Yup.<p>On the one hand, often there can be shared lines of code without a shared idea, this shouldn't be a candidate for being factored out into some new abstraction.<p>On the other hand, you <i>may</i> want to introduce an abstraction and factor out code into a common library / dependency / framework when there's a shared well-defined concern/responsibility.<p>That said, on the gripping hand, I say <i>may</i> because even if there's the opportunity to introduce a clean future-proof abstraction, introducing it may be at the cost of coupling two things that were not previously coupled. If you've got very good automated test coverage and CI for the new common dependency and its impact upon the places it is consumed, then perhaps this is fine. If the new common dependency is consumed by different projects with different pressures for change / different rates of change / different levels of software quality then factoring out a common idea that then introduces coupling may cause more harm than good.