Updating third part libraries does and don’ts

Projects often use third party libraries, which code interfaces to. As the same held for your project, the third part libraries also involve during time. Issues are fixed, new features are added, but also possible new issues will be introduced. Should you update, and keep track of the latest greatest library or use the argument “if it ain’t broken don’t fix it” and stay with the old? What are the pro’s and con’s of each scenario?

Updating not

Sticking to the old version of the library, creates a controlled environment. You’ve tested your code against the library and do have unit-tests in place. The tool is used by your customers and you did there a great job. At least the external components stay at the same quality level.

However, the new library might have fixed problems which fix yours. Also old versions can have major security leaks, which have been fixed in newer versions.

Update the library

Updating the library might change the level of quality of your external components. Problems that can occure are introducing side-effects of already tested code of your product. Think of a change of flow of the updated component.

On the other hand, when you do have problems, a new version may fix issues but also introduce new ones. Look at the release notes of the libary. Has it fixed potentional problems you’ve encountered in your code?

When you’ve decided to update

When you’ve decided to introduce a new version of the library, what should you do? First of all add safety nets in the form of unit tests. These unit tests will test the library for the calls you require. If one of the tests fails, you have a hint this might not be the right moment to switch to the new version of the library. If you don’t have any tests that will verify the library, you don’t have a clue you’re code broke some functionality or the libary did. If the issues are small, you can suggest fix them right away. If they are more complex, this would not be the time to upgrade.

When you do wan’t to update your libraries at a regular time, try to keep up in pace with the introduction of new versions of the library. The delta’s are rather small when you have the same pace. When the delta’s are rather big, it is also more difficult to trace down issues.

Design with facade pattern

Having a good design will make the integration process a lot easier. A way to let the external library communicate with your project is via the facade pattern. This has multiple benefits:
– Makes replacing the library more easier with another library.
– Also it identifies the interfaces between your code and the library. This also makes stubbing for unit testing a lot easier.
– Exceptions can be handled at a central point, which makes detecting problems with the third library easier by pin-pointing the problems.

Hope this will help you to decide whether or not to update your external library or not.

Posted in Best practices, Design patterns by Bruno at August 10th, 2016.

Leave a Reply