Ensuring that each of libraries has significant amounts of automated testing included means these libraries become self-documenting and show other engineers how to use them.
This benefit will be nearly automatic if we have test-driven development (TDD) practices in place. Any engineer wishing to understand how to use the system can look at the test suite to find working examples of how to use the system's API.
Ideally, each library will have a single owner or a single team supporting it, representing where knowledge and expertise for the library resides. Furthermore, we should (ideally only allow one version to be used in production, ensuring that whatever is in production leverages the best collective knowledge of the organization.
When Development follows their work downstream and participates in production incident resolution activities, the application becomes increasingly better designed for Operations. As we start to deliberately design our code and application so that it can accommodate fast flow and deployability, we will likely identify a set of non-functional requirements that we will want to integrate into all of our production services.
Implementing these non-functional requirements will enable our services to be easy to deploy and keep running in production, where we can quickly detect and correct problems, and ensure it degrades gracefully when components fail.