I used to be an passionate proponent of the [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) principle, that is, to keep code as deduplicated as possible. Now I'm not so sure anymore. It turns out, that creating a shared library to keep things DRY comes with quite some downsides as well: - introduced coupling between otherwise independent teams could lead to slower changes and delays in deployment - the requirements might not be exactly the same across the clients (and across the different domains where the library is used), leading to different flows and complexity being introduced in the library - making a change might be harder, because all clients now need to align or accept the proposed change - developer experience could be harmed, such as by introducing private library repositories that needs to logged into from CI pipelines, and such. > Shared libraries are not a good thing in general. They add a lot of overhead in this case, but more importantly they also add lots of unnecessary dependencies and complexity, and almost no shared libraries are actually version-safe, so it adds absolutely zero upside. > > I think people have this incorrect picture that "shared libraries are "inherently good". They really really aren't. They cause a lot of problems, and the advantage really should always be weighed against those (big) disadvantages > - Linus Torvalds, in the [Linux Kernel mailing list](https://lore.kernel.org/lkml/CAHk-=whs8QZf3YnifdLv57+FhBi5_WeNTG1B-suOES=RcUSmQg@mail.gmail.com/) > If a team delivering on a single feature has to coordinate with 2 or many other development teams, it only creates delays and challenges for all of these teams. That's the notion of locality. > —Gene Kim, author of the Unicorn Project Some more reading: - [Don't Share Libraries among Microservices](https://phauer.com/2016/dont-share-libraries-among-microservices/) - [Goodbye, Clean Code](https://overreacted.io/goodbye-clean-code/)