background

Package Updates

Every company has that one task nobody wants to tackle.

Sometimes it's repetitive and boring; other times, it often leads to issues for customers or colleagues. In other words, it's that unpleasant task you avoid like the neighbor you don't want to run into.

In my developer world, that's the Monthly Package Update. This dreaded task creeps up at the start of each month, demanding attention and care from the poor developer assigned to it.

Jokes aside, keeping every library up to date is crucial, if not vital. Postponing it only causes more trouble the next time an update is scheduled. Ignoring it will make our code quickly obsolete, eventually requiring a major migration or even a complete rewrite.

Why is it so painful then?

It's not as satisfying as writing a new feature because, in the end, we just want everything to work and look exactly as before.

  • Upgrading libraries can cause side effects. Some introduce breaking changes that require rewriting parts of the code.
  • This demands extensive manual testing, as not everything can be covered by unit, integration, or e2e tests.
  • Some dependencies can conflict with each other, making the update harder and forcing us to decide which libraries to update now and which can wait.

As part of our developer routine at ICFM AG, we commit to regular updates. Yes, it's painful. No, nobody wants to do it.

But there are too many good reasons to just eat the frog, tackle that monthly task, and get it done.

Maybe nobody will notice. But that developer is the hero of the month.

Whether you're a frontend or backend developer, when that day of the month arrives, run. 🏃🏼‍♂️

Run fast. 💨

Or be the hero! 💪🏼