Shared Libraries

Long-lasting teams will sooner or later end up with more than one application even if they don’t go all the way to microservices. Avoiding duplication is a key issue in software development. Since you can’t access your code in every service without putting it into a shared library, the need for such a library will almost immediately arise.

Don’t put everything into one library

The most common solution: One common shared library which is used for all the code that may be reused in different services or applications.Authentication, basic database layer definitions, integration test setups, excel document export and much more lumped into one library.

Imagine you are a developer in a team that needs to update their authentication from Basic Auth to OAuth2. Everything has been prepared in the shared library. You just need to update the library and configure the authentication.Then you encounter the first problem: In the latest version of the library, the document export (which is also part of the library) was changed to meet the requirements of another project. Now you need to fix all the compiler errors surrounding your document export first. And the syntax for the listeners on your database layer changed. You need to fix that as well. Maybe, you want to test your fixes first before continuing with your original change? This takes time as well.

In this case, you are forced to update everything contained in shared library simultaneously. You can no longer choose when or what to update. However, the worst part is that this forces you to do context switches between different parts of your application which will simply slow you down. This is well documented in [Jeff Sutherlands book (page 87) 1]1. So even if you want to update anyway, you may not be able to organize your work in the way you want.

Learn from the open source world

The obvious solution is to divide your library in a similar way people do it online. If you take a look at GitHub or GitLab projects, you will usually find libraries which do one thing only. If you need to create an excel document you use one library which does exactly that. The excel library you find online don’t contain an OAuth2 module.

Conclusion

Organize your shared code the same way people do it online. Split it into different small libraries which all cover exactly one concern.

References

[1]: Scrum: The Art of Doing Twice the Work in Half the Time, 2014, Sutherland, J. and Sutherland, J.J.