About updating dependencies

About updating dependencies
Photo by Maria Lysenko / Unsplash

Did you notice how different communities manage their ecosystem? How for the most part most communities want to have the most up to date versions? Of course, we want the shiniest and most feature complete versions of our software.

Always having the most up to date versions of something is not always desirable. Specially in production, but we can also agree that having old outdated software isn’t an option. Or is it? I would say that, in my Erlang experience, we need to have a good balance between the two.

In general we trust the ability of our own code to scale, but we don’t trust our dependencies. We have to know and understand the inner workings of each one of our dependencies before using them in production.

Developers in general don’t test their libraries under heavy load. And many start changing their behavior when you push your system and dependencies to their limits. An extremely common example is when libraries need to store state, in Erlang, they usually rely on gen_server, which will work just fine until you push to prod and you get out of memory very quickly.

Another not that common example in erlang, is when you have a dependency which calls C code. If the C code doesn’t finish fast it basically destroys all the scheduling. EVM loses it’s preemptive scheduling capabilities if it’s not executing erlang code.

There are many other considerations like, does this lib uses any kind of pooling, how does it scale? it’s internal structure can handle all the call we will be making?

When I was a RTB developer I didn’t just update the dependencies. It was a separate task on itself: I had to read all the source-code changes, and search in the mailing lists for any problems other developers had, and only then if sufficient time passed I started updating the dependencies. Where for the most part I tried to always be one version behind the last one.

When I worked doing RTB we even had to be able to answer yes to any of these questions, before we were able to use a new dependency:

  • Is it a critical update that without it our system crashes?
  • Is it indispensable for our system? and it doesn’t make sense to write our selves while at the same time you know the inner workings of it?
  • Do you have production experience with that particular dependency?

The more moving parts we have the more complexity we get, and the more frequent we update our software we add even more complexity and bugs. The emergent behavior of our systems can’t be predicted.