The nuances of updatability

This blogpost labels the nuances, downsides, limitations and side-effects around different processes of updatability. This blogpost has the intention of clarifying the complex landscape of updating software, in a push for a good approach by Compony. 

This blogpost is the second in a mini-series where we explore the different facets of updatability:

  1. The different update processes currently in existence.
  2. The side-effects of each of these update processes. (This blogpost)
  3. Inspecting Composer and NPM’s updatability.
  4. Updating Compony components.

Evergreen’s indifference #

The evergreen concept is an amazing concept for the software that gets updated by it. But it also suffers from holding an indirect risk of indifference. This risk arrives when you build software that you write on top of this evergreen software.

For example, let's say you were to build a browser extension on top of an evergreen browser. The browser extension will always have to stay up to date with any change this evergreen browser is introducing. There is a good chance, that at some point in the future, an evergreen browser will be indifferent to breaking the functionality of certain browser extensions.

Browser extensions are built on top of the software of browsers, so the risk of this indifference is completely on the side of the browser extension. This again, makes loads of sense: in the bigger picture, It’s wise to prioritise the stability of the browser over the stability of the browser extension. 

There is a small nuance: there is a mutual benefit between browsers and their extension ecosystem. Because of this, the developers that work on browsers, tend to avoid to play the indifference card as much as possible. Browsers therefor give the extension developers the chance to test their code on a dev-version of the browser. This dev-version will be very close to the version that gets released in a evergreen manner to millions of devices. This gives the extension developers a timeslot in which they could test and possibly update their extension to be compatible with the current version and the future version.
 

Subjective derailment #

There is a chance that a browser will implement changes that you find annoying. For example, a browser might update their visual design or user interface. As humans, we have the tendency to dislike change that we didn’t choose ourselves. But by using evergreen software, we give away the choice of which version of the software, we would like to use.

Again there is a nuance here, because there is a benefit for the developers of evergreen software to not annoy a subset of their end-users. They do this by offering opt-in for visual changes. This allows the evergreen software to track how much their new opinion is appreciated and chosen. And they can keep evolving for the users that do opt for the new changes.
 

Assumption of knowledge #

As explained in the suggestive update process we usually get 2 suggestions: either update or don’t. While this makes a lot of sense for the programmers making this 2-choice option, it brings along the assumption that people know what they are doing. 

The mere existence of a choice in updating, implies that both options are completely valid. This choice between 2 valid options in turn then implies that people need to know about the implications of each choice. 

For example: If you ask a web developer why they took the decision of updating their browser when they got that notification, their reason might be that they read the release notes or are concerned about security more than about stability. In contrast, if I would ask my grandma why she updated Chrome, she might claim that her Google search didn’t show her very relevant results.

We often forget that a big chunk of humanity is scared of updating something that works for them. Giving people a choice implies that there are benefits to both options, otherwise, why would you bother asking them the question? Often people will see that choice as something scary, and freeze on the spot and decide that just now, is just not a good time to be brave.

As a front-end developer, I might be keen on updating my JavaScript libraries, but I'll likely skip updating that virtual box after finally got it to work.
 

Schrodinger’s security #

When we are using software that is maintained with an update process, we get the feeling of stability. The software doesn’t ask us to update, nor are we assuming it is at any point in time critical to run updates.

At the same time, this software will be incapable of alerting it’s users to update, In case it detects a security breach. Because we have to manually check for updates at any point in time, this software that we are using is both secure, and not secure, and we will only know once we check for updates. Giving us a process that with some artistic freedom could be called Schrodinger's security.

Untouchable code #

An update process, will remove an old version of the code and put in it’s place, a newer version of that same code. That means that if you edited in the old code, your edits would disappear every time you update.

Updatable code therefor becomes “untouchable”, because any change you do to it, will be made undone with the first time you update that code.

Some examples of this are: Drupal core, Drupal contrib modules and npm packages. 
 

Unread release notes #

If you update for example a browser, you could read a summary of what changed, because you update one software package. In programming however, this is rarely the case. 

If you update your Composer packages, there is a good chance you will update a dozen packages. Each of those packages will have at least one or more release notes. If you update NPM packages, those numbers could be easily multiplied by 100. 

The more we rely on code we haven’t written ourselves, the less likely it will be, that we will read all the release notes. 
 

Blind updating #

A good example of updating blindly is updating npm packages, which feels often like playing Russian roulette. You will only play it, if you have no other choice.

If there comes a time that running updates is required because of security. Then you’ll have to look down the barrel and pray to your god(s). Hoping that those security warning silently click away, without causing mayhem. 

We update our npm-packages in the hope nothing will change functionally. So while we only wanted to fix security updates, we are blind to the other changes we brought along with us.

If updates go wrong, we usually have to remove all of our packages and run the install script again. This is where the blindness comes in: we no longer care about what the code does, we just want that security notice to go away. But if we no longer care about the code that we are updating, the question arises, can we still call it “updating” and shouldn’t we call it “burn it down and build it up again”?.
 

Un-updatabe languages #

You can hook in to downloaded 3rd party PHP-packages with custom PHP or call certain functions defined in npm-packages from within your custom JavaScript. Conceptually, this means that you can interact with a 3rd party package, without editing it’s source code. This concept makes those 3rd party packages updatable, because we didn’t edit inside of them. 

But there are other programming languages where this is impossible. For example: HTML is a declarative language, as it only describes what should appear on a webpage. We can’t hook in to HTML, or pass variables to it directly from other HTML. However we do have Twig where we can pass variables to, extend with, and alter using Twig blocks.

Yaml has the same declerative behaviour, you can’t hook in to a Yaml file.

The CSS language is another example, you can’t interpret one CSS file from another CSS file. If you want to pass variables or hook in to this, then you would need to use a preprocessor such as Sass or Less and do your altering in there.

The nature of these languages makes them close to impossible to update in a streamlined process. When a developer working on a Drupal contrib module wants to change the HTML their module outputs, they are advised to create a new major release. For example: if they want to change a <div> to a <button>, then it’s impossible to know how many projects that are relying the output of that module to render a <div>. For example: a project that is relying on this contrib module could have CSS depending on the element being a <div>.
Therefor the guideline the Drupal community defined is: when you change something in the markup, you should create a new major release. (Ref: Semantic versioning)

The same logic is applied for the smallest things: as a developer on a Contrib module, you are discouraged to update even a class in HTML, as there is no way of telling how many custom themes are relying on the existence of that class.
 

Published 07 December 2019
Updated 10 January 2020