Diego Pacheco Tech blog

Internal shared Libraries are a trap . Sorry, not one trap, multiple traps because often there are multiple internal shared libraries. Engineers often take libraries for granted and fail to see the hidden costs in libraries. Libraries should be designed carefully . Libraries provide functionality, code reuse and allow us to be productive to some degree. I’m not against the usage of libraries. However, we need to understand that libraries have issues and hidden problems. For instance, productivity cannot be measured only on how fast you get things done in the sense of days, number of user stories, or releases. Several side effects need to be taken into account such as: Bugs: How many bugs did you produce by direct or indirect usage of a library. Incidents: If the bug creates a major incident, how much money did you lose, and how much your customers got affected? Any brand damage or loss of trust of your users? Debugging & Troubleshooting: How many hours, do teams spend debugging ...

This is not a new post, this post is related to other posts and issues that I'm talking about in this blog for at least +10 years. When I started doing SOA I fall in love with it because was all about Services and not about libraries. +15 years doing SOA and this problem still exists in the industry. Dependency management is a lost discipline, and it's super needed nowadays. Every company on earth has internal shared libraries. However, libraries often are a huge trap . There are ways to deal with this issue. The biggest problem often people dont realize is that OSS libs are often maintained by small teams that cannot afford to maintain several old versions of libs for free. Some companies behind popular and big OSS solutions have a paid support service where often you can bigger support for longer. However, that's not the reality for all and the majority of libs out there. Often product teams are focused on release features. Product teams often dont have Slack . The outco...

I personally have a deep passion for lean libraries. Binary Coupling and distributed monolith kill all services initiatives. Shared libraries are often controlled or done with attention and care. The result is catastrophic, developer experience goes down, the ability to the chance version in isolation goes to space and complexity grows as productivity and migrations become more and more consuming. Tinylog has my respect. I love simple, no 3rd party dependencies libraries. So today I want to show how tinylog is cool and yet powerful. I made a video and a simple Scala project using SBT. So Let's get started,