Why Developers Hate Changing Language Versions

Progress powers technology forward. But progress also has a
cost: by adding new capabilities and features, the developer
community is constantly adjusting the building blocks. That
includes the fundamental languages used to code technology
solutions.

When the building blocks change, the code behind the technology
solution must change too. It’s a challenging and time-consuming
exercise that drains resources. But what if there’s an
alternative?

The problem: reading code someone else wrote

Let’s take a step back and take a look at one of the fundamental
challenges in development: editing someone else’s code. Editing
code you just wrote, or wrote a couple of weeks ago, is just fine.
But editing your own code written years ago – never mind someone
else’s code – that’s a different story.

In-house code style rules can help but there are always odd
naming conventions for variables and functions, or unusual choices
for algorithms. Arguably, a programmer’s ability to read code is a
key skill – but it’s tough for everyone.

Developers call the process of editing old code “refactoring”
and it’s a process that commonly introduces new bugs or performance
problems. So that’s why, going back and editing old code, well –
that’s the last thing most development teams want to do,
particularly when the existing code base is running stable and
doing its job.

It’s a real headache, but sometimes there’s no alternative

Refactoring is something every developer wants to avoid for as
long as possible because it can feel like a waste of time.
Nonetheless, developers must refactor from time to time for a
variety of reasons, and one of the most common reasons is due to
changes in developer building blocks.

That includes changes to the programming languages used to build
software, which inevitably evolves over time. New versions of a
language will often deprecate old ways of doing things while
introducing new features. If developers don’t adopt the new
language version, they’re excluded from the new feature set.

However, existing code usually needs adjustment to run on the
new version of the language, and that implies a refactoring
process. And that’s the conundrum: to adopt the new, more advanced
version of a language developers need to refactor, and along the
way they’ll spend a huge amount of effort – and break all sorts of
unexpected things, introducing new bugs into an application that
was running just fine.

Worse, refactoring alone doesn’t give you the advantages of the
new language version, instead you need to redevelop your codebase
to tap into improvements. Otherwise, despite adjusting the code to
fit the new language version, you’re just where you used to be: a
codebase running on a new language version, but with no new
features.

Vendors commonly leave end users to deal with it

It can seem like a pointless exercise but, with the steady march
of technology change, there’s often little choice in the matter –
with your technology partners choosing for you.

Let’s say we’ve just moved from Python 2.7, to Python 3.0. If
you’re developing your applications in-house, you’re in full
control and can make the shift, or not make the shift. Developers,
on the other hand, may well decide to leave things be. If an app is
developed for and runs on Python 2.7, the developer will just leave
it at that – and tell users an app was developed for Python 2.7,
with no support for other versions.

It can leave users in a tough spot – stay on the older version
of Python 2.7 to accommodate the application, leaving behind
progress, or switch to Python 3.0, and risk a range of
incompatibilities with apps.

The net result: a major security risk

Programming languages (and their assorted libraries) are not
immune to security vulnerabilities. When these vulnerabilities do
come up, a language version upgrade can be forced on you by the
developers.

But these upgrades will not be limited to simple bug fixes –
they will bring along deprecation of language constructs with new
constructs brought in, and that will force developers to go through
the motions of doing changes to existing code, again with all the
potential issues that brings.

The situation gets even worse when you think about the
compounding effect of included libraries. After language changes
these libraries must be updated too – but if one of the libraries
in use is not updated by its authors, the developer won’t be able
to use it after upgrading the rest of the code to a more recent
version, again leading to more code writing.

It’s easy to see where it all leads: more effort, additional
risks of introducing bugs… and a reluctance to carry on refactoring
to accommodate updates. Next? The updates simply don’t get done
which means that workloads rely on insecure, outdated building
blocks.

The story is similar to what we see play out all over the
technology world, as old and vulnerable building blocks leave the
door open to cyberattacks. There is, however, some good news
emerging.

Is there a better solution?

Take unsupported operating systems, for example. In the past,
when an OS reached end of life^[1], the only choice was to
upgrade to a newer OS – a major investment, and full of risks. The
net result is that many organizations rely on unpatched,
unsupported operating systems even for critical workloads. If you
don’t have updated applications, because developers won’t refactor
old codebases, you can’t move your applications to newer operating
systems that don’t support the old versions of the language – and
thus break the application.

Thankfully, this scenario changed as end of life support is now a reality for
many Linux operating systems^[2], which means that
organizations can buy time to migrate away from an unsupported OS
to an OS with official vendor support, without taking any security
risks.

Can something similar be done for language versions? A way to
effectively “upgrade” a language runtime with the latest security
fixes while at the same time not changing how that specific
language version or libraries otherwise work, thereby removing the
need to refactor?

Repeating what’s been achieved for operating systems and
applying it to language versions will give developers enormous
breathing room, reducing the need to continuously refactor. In
turn, there’s a higher probability that workloads run safely and
securely.

Is it possible? Well, what was achieved for operating systems
can be expanded to other areas. Watch this space.