The importance of upgrading technology regularly

Photo by Szabo Viktor on Unsplash

First of all, I apologize for the very generalistic and probably too broad of a title.

I am certainly aware of the fact, that the term “technology“ encompasses a wide range of things and meanings to different people, so let me narrow it down a bit. The technology I will refer to is mostly software, think of programming languages and their versions, middleware, framework versions, and so on.

The problem

So we are talking software or web engineering here. And while this could be applied to hardware and other things obviously, the big difference would be the cost. Upgrading software merely costs a bit of time (when speaking of Open Source software at least) to upgrade and test if nothing is broken, while upgrading on hardware could cost a fortune, depending on your situation. But you get the picture of what this blog post is about.

Now I know, there are already tons of articles and whatnot regarding this topic floating around in the depths of cyberspace, so why putting out another one you might ask?

Simply put, this is my attempt to be another voice of reason why updating makes sense and should be done regularly.

Throughout my career, I have come across countless projects, where the codebase and/or the surrounding technology was (half-)abandoned, a decade-old, hopelessly outdated and quite frankly, a ticking time-bomb in terms of security. Bonus points if the technology used was some obscure thing that might have looked promising back then, and somebody (probably some poor single developer assigned to do the whole project) just happened to be proficient in said technology. Of course, this guy had long moved on since and even left the company, so nobody really understood the whole codebase and the technology. Or, in some cases, he was able to pass on his knowledge but the technology simply died off years ago and because it runs “just fine“ in production and probably generates some sort of revenue for the company, it would be hard to justify rebuilding it with up-to-date, state-of-the-art technology. At least from a business (read managers) perspective, that is.

So instead, the outdated application got patched as time went on, while the application got more and more disliked by the unlucky engineers who were put in charge of it (yes, that often was me).

Let me give you a quick overview of the consequences this has:

• The community moves on, which shrinks the available resources around the technology
• When the technology gets abandoned, it will not receive any more updates, which might be critical in terms of security
• Engineers are forced to work with outdated technology, which might impact their motivation. No engineer wants to work with something which will not be of use in the future.
• If you finally have to upgrade things, it will be much more challenging to do so, because there will be more significant changes and incompatibilities when you upgrade from, let’s say - version 1 to version 5, instead of gradually upgrading minor versions every couple of months or so. Eventually, the time spent on this, as well as the level of frustration it brings, will be exponentially higher. It will also cost the business more money.

There has to be a better way, right? One, that makes business owners, stakeholders, customers, and engineers happy.

How to stay on top

Let me tell you how we are doing things here at Offskip.

As a general rule, upgrading minor versions is encouraged and does not need any kind of special approval. It is simply a part of the development process. The key here, however, is to have reliable automated tests in place. So upgrading some dependencies or the framework usually is no big deal. We simply run our tests and fix whatever issue pops up. This works well in 99% of all cases for minor version upgrades.

So, what about major updates? The likes which for sure introduce breaking changes and incompatibilities?

For those tasks, we usually do some Research & Development activities. Usually, we would gather information related to the technology we use, such as information about recent or upcoming releases, new features, and breaking changes.

When a stable version is out, we do a test with said version and if all works well, we schedule company-wide upgrades. The engineers in charge of the tests will not only provide the necessary steps to efficiently perform the upgrade, but also about the pitfalls and issues encountered, if there were any, and how to overcome them.

As an example, in the last quarter of 2020, we researched upgrading from Vue 2 to Vue 3 and from Laravel 7.x to Laravel 8.

Since we gained a good understanding of the differences and challenges ahead, the actual upgrade is going fairly smoothly.

Upsides

By allowing us to spend a bit of time to keep things up-to-date and refactor code, we avoid building a “legacy“ project in the first place. As a rule of thumb, if something is being used, it should be maintained well, and that includes keeping it up-to-date, with everything included.

Granted, in a lot of cases, the user will not know or notice any difference about changes in the underlying technologies (a subtle performance boost maybe?), and managers and stakeholders need to be made aware of the necessity, but even if the difference is mainly seen and felt by the engineers working on a project, I believe the web is a better place when driven by safe, performant and up-to-date technology.

So to summarize why you should upgrade your technology on a regular basis:

• Safety and security
• Performance
• Potentially new features are being introduced in new versions, making the engineer’s life easier, enhances performance, security, etc.
• Finding talents familiar with said technology is easier when looking to fill vacant positions (also, the more popular a technology is, the easier it is to find engineers)
• You avoid having legacy code because upgrades often force you to revisit your code
• Maintainance is easier since it is kept fresh in the memory of the engineers
• Engineers work with new technology, which boosts their motivation as well as their skill set.
• But most importantly, you avoid having code some poor guy has to look at after years while having a mental breakdown, or at the very least, a big “wtf?“ moment

Downsides

What about the downsides? Here are some of the obvious ones:

• You need to invest a bit of time to stay up-to-date with your knowledge about the technologies you use (which makes sense to do anyway)
• In some cases, the plan to upgrade a simple thing like the framework or some dependencies can turn into something bigger if you find that the underlying technology (such as the installed version of your programming language or some middleware) is not compatible with the new version of your framework. This has also an impact on the infrastructure overall and would need to be planned carefully over several departments or company-wide. Possibly some form of approval is needed too, especially in bigger companies and depending on your position in the company.
• Some people might feel uncomfortable with constant changes(?) Not sure if this is a valid argument since most of us replace our smartphones every couple of years at the latest, which is in most cases a bigger change than a simple software upgrade
• “Shouldn't we instead implement feature X or fix bug Y?”
  Something like this usually comes out of the mouth of somebody who is not an engineer, think managers. The reason for this usually is money. Obviously the faster you deliver a new feature or fix a bug the better. It is true that those things will deliver direct value, but it neglects the fact that keeping things up-to-date delivers value too.
  Let’s say you upgrade your framework and it brings performance improvements and some sleek new ways of writing certain parts of your code.
  First of all, the performance improvement is obvious, but beyond that, you can now write better code, it is more readable, easier to understand, easier to maintain, easier to test. This makes the developers' life easier as well, and down the road, you will have saved time and money.

Conclusion

So, as you can see from those examples, it boils down to the old question of “Wait until it is no longer bearable and then do everything at once” or “Do small steps every now and then”. In the end, it is up to you, really.

However, I hope with this article I was able to explain why it makes sense to keep your technology up-to-date, to do the “small steps regularly”, the risks of not doing so, and how you can do it in a way that does not cost the company a lot of time and money.

I would love to hear how your company deals with legacy technologies and upgrading them!