Tag: upgrades

Start now

If you have some technical debt, an architecture issue, an old bug, or just some poorly developed features, now is the right moment to start changing. And I’m all pragmatic about it. No motivational stuff.

I’m talking about real problems which hold you back, waste time and money. Not about small optimizations which don’t bring you value, not every problem needs a solution.

To start doesn’t necessarily mean to actually do or to rush, you can start analyzing the need and the effort, think of required steps (technical analysis, people analysis, business requirements and so on).

Then start refactoring that old class or make a new one, maybe extract that feature into a microservice, upgrade that server, change that old technology, rethink that architecture so you can change easier in the future.

You know your business, but get fresh ideas from other people, maybe you’re too stiffed after many years on the project.

Just start the process now, because later everything will require more and more resources.

 

If it’s not broken, fix it before it will be

I’ve recently read a discussion on server software upgrades, and someone was recommending not to upgrade if you don’t have a problem.

My approach is a little bit different, as in I advise you to upgrade from time to time (at least) your OS and packages. In “the real world” it’s not often easy to do this, but if context allows, you should do it. You should prevent unwanted situations, instead of fixing them after they’ve done damage, and maybe suffer consequences.

A basic approach (in a decent context) would be to make upgrades in test environments. After you make sure you’re ready for production upgrade, redirect traffic to some new temporary machines before updating main machines. Of course, if you have your own load balancer instead of a DNS one, it’s easier to do this. Don’t upgrade directly on production, don’t assume nothing could go wrong. Back up data before!

The same goes for code libraries. I’ve seen upgrades being ignored because “we don’t have time now”, and ignorance. Then a moment came when they were forced to make the upgrades, because new libraries were depending on new versions of the existing ones. You should have seen the “joy”, and the bugs which followed in production, as there was no time to test everything as it should have been.

Upgrades can be a pain, they can crash, they can take time, new packages can have issues. However, this is not a reason to ignore them.