Today I’m going to touch on something that is near and dear to my heart as an engineer, and that is breaking changes at scale. Granted there are industries and armies of consultants dedicated to the concept of change management ranging from ITIL to Agile/Scum. At the core, the focus is on documenting the change request and resulting change. My question to you is who creates the request and how, who is aware of the change being made, and how is the resulting change announced?
For product and SaaS based companies, these kinds of questions usually start with a customer or target audience. For a product based company, they will usually end with a new thing to download with release notes documenting what’s where. If you’re someone like Apple or Amazon, then you’ll have the official product announcements, or if you’re Amazon, Oracle, or Microsoft, then there will usually be a weekly announcement of new features and an occasional webinar. For SaaS companies, you may see an announcement if you are subscribed to their change announcement newsletters. However, if you are Facebook, then the only time you will see a change is usually when you access their website.
Ultimately the target audience is easy to figure out as they are the end users or the implementers of the software. More than likely there are no standards body associated with the software as it is controlled by a single organization. Now let us take this up a level where there are multiple stakeholders involved. The most common example these days would be open source projects such as OpenJDK, OpenStack, and the CNCF for all things Kubernetes. In these cases there are several companies working together on a common set of standards and software for the betterment of everyone allowing for interoperability between dependent software, and common set of changes. Granted each vendor can add in their own features, but there is a core set that is considered reasonably stable. Changes are intended to be slow due to the numerous players involved, and because it impacts end users, developers, and dependent tools. Changes are deliberate and processes are in place for adding and deprecating features that the tools will notify the user about if they aren’t following the project directly or spending their nights pouring over the release notes from the github project page. The point being that the ultimate consumer, while they may not have received the “official” notification from the vendor about a change, they will usually see a negative impact in the tools that are being used and can plan accordingly.
This takes me to the W3C, WHATWG, and web/browser technologies. There is nothing more complex and critical than anything touching the world wide web. Borrowing from the Matrix, you can’t really describe it as it is everywhere and everything. It is in your computer, your phone, your car, your television, your refrigerator, and even your doorbell. It surrounds our more dynamic and interactive world, and at it’s core, the design is so simple that you can create your own web page and view it on a web browser without a network connection, and some websites that were written in the early 90s will still work with today’s browsers. Mostly…
The w3c has been the primary standards body since the formation of the web and consisted of industry and academic players. If you can think back to the 90s, there were multiple browsers ranging from NCSA Mosaic to Netscape Communicator (basis of Firefox), and Internet Explorer. In fact, there were even text based browsers for those using the UNIX terminal (lynx and links). The guiding principal was backwards compatability, and as features were developed by the vendors, the standards body would pick it up. However, as soon as a system becomes critical infrastructure, it becomes legacy.
From my recent discovery of WHATWG, this appears to be the industry’s attempt
prevent that (from https://www.theregister.com/2019/05/29/w3c_whatwg_working_on_one_html_dom_spec/):
WHATWG originally split from W3C in 2004 in response to the latter’s sluggish approach to standards development. It was founded by individuals from Apple, the Mozilla Foundation and Opera Software.
In essence, there are two competing working groups for the web, one driven to maintain the integrity of the current ecosystem, and another driven by the browser vendor’s desire for change. But what does this have to do with the original topic? I stumbled upon an article written in the Register a couple of weeks ago looking at Google’s unilateral decision to remove a core piece of functionality from the web specification. Granted, it isn’t used too much these days as a lot of web frameworks have created their own implementation of similar functionality. I won’t go into the technical nuances involved, but it highlights how Google went about introducing the change. In particular:
- Change was filed in Chromium issue tracker
- Proposal was submitted to WHATWG
According to the article, it wasn’t until a developer working on the change posted their work on twitter that others were even aware of what was going on. In this case, we are somewhat lucky in that we had to rely on Twitter to discover the change instead of upgrading our web browsers, and wondering why something used to work stopped. The crux of the issue is that unless someone happened to be following the Chromium project as a contributor, and happened to be a member of WHATWG, this would more than likely slip under the radar. Here everyone is impacted, and even if you are a web developer, you more than likely would not have known about this change either. I know I would have been surprised to have tried to use this pre-existing feature to debug something to only realize after banging my head against the wall that it was removed.
In my personal experience, this isn’t the first time Google did something like this. The last two major changes I can recall involve third-party cookie support while an attempt to clamp down on ad trackers also has an impact on organizations that run multiple domains and have a centralized session/identity management system, and altering how certificates are trusted. Ultimately, these are positive steps overall, but my critique is more on the unilateral decision of a particular vendor in a take it or leave it approach, and the lack of a meaningful transition period where an upgrade breaks the world instead of letting you or your IT team know that a change is required, and you are left scrambling to either clean up the mess, or keep your organization on a web browser version that will be vulnerable to bugs as they are discovered in the future.
Google’s defense is that they did let people know, but were they the right people, and was it somewhere other than the release notes page that most people would not read prior to the automatic upgrading of their browser?
I will leave you this thought exercise: how do you communicate your changes with your end users and customers? Is their any change to their workflow as a result that wasn’t accounted for?