Continuous delivery and ruining the user experience

“I was chatting with a random Canadian woman. She found out I worked for Mozilla and I got that sinking feeling, like “here we go again” because I knew exactly what was coming up. She proceeded to tell me the story of how she switched to Chrome because Firefox kept breaking her extensions and asking her to restart.

I’ve heard this story a lot in the last year.

I used to be proud to say I worked (or had worked) for Mozilla, but a careful listener might detect a certain sheepish quality that has crept into my voice lately when I name-check my former employer. And this is why. Even on the opposite side of the world, it’s always the same story: “I used to love Firefox”, but “I switched to Chrome because my extensions stopped working” or “I switched to chrome because Firefox kept asking me to restart”.

I’ve had this conversation with dozens of people across three continents. Not one person has had anything good to say about the rapid release process. Nearly 100% of my highly unscientific survey volunteered the information — unasked, unprompted — that the rapid release process had ruined Firefox for them.

Of course nobody says “rapid release process” because people don’t know that’s what it was called. They might start out complaining about version numbers, or some plugin that doesn’t work right, but when I ask enough questions to get to the root of the problem, it’s always the rapid release process.”

This article, by an ex-Mozilla developer all but confirms what I wrote about here nearly two years ago:

“The only downside I see to continuous delivery is when it’s used in an environment that needs to be actively upgraded by users; it’s no point pushing out new functionality daily if your users have to do an upgrade daily.”

I am at a point where after 8 years of using Firefox as my primary day to day web browser, I am seriously considering switching to using Google Chrome primarily. I find the Firefox rapid release process ridiculous: who releases a major version upgrade every few six weeks that appears the same as any previous version? And each version requires new WebDriver binaries, unlike Chrome.

I see the iOS update issue becoming more and more prevalent as we have more iDevices in our household that need constant updating. Other annoyances include Adobe Flash on the desktop (every second day it seems), Mac OSX installing updates that need restarts and paid OSX apps now require running App Store on Mac to check for updates. Madness!

Author: Alister Scott

Alister is an Excellence Wrangler for Automattic.

7 thoughts on “Continuous delivery and ruining the user experience”

  1. The WebDriver binaries issue is what kills it for me. All of a sudden I can’t run any WebDriver tests because I’ve upgraded Firefox, so I have to manually downgrade. It’s probably not a huge issue, as most users aren’t using Firefox for automated testing… but for those of us that are, it’s maddening.


  2. It’s an interesting thing you pointed out. Does it look like one piece is missing in Continuous Delivery re smooth update?

    BTW, My browser timeline is Netscape > IE > Firefox > Chrome > (Joined Apple World) Safari > Chrome.


  3. Fully agree with Ben Burton — it’s called “native events” and it breaks every version or two, as Selenium is forced to update their code to support the new version. It’s the first time in my life where (at work, where I use Firefox for automation), I’m deliberately *not* upgrading to the latest, greatest version.

    I’m fine with CI and rapid releases, as long as it’s not a big burden on the user. When I compare Firefox’s style to Chrome or uTorrent or Steam — those latter apps all make it very easy for me to restart. All open tabs and what not start up again immediately. Firefox updates are awkward.


  4. Actually, I’m not sure if what you’re talking about here has anything to do with continuous delivery. There is no reason why a company can not / should not release regular updates to software, if the update architecture is right. As a general rule, you won’t get a huge number of code changes during a given 6 week period, especially once you’ve considered testing and stabilisation into that 6 weeks. That Firefox cannot cope with these minor version changes without breaking plug-ins is surely an indication of the poor quality of the plug-in architecture of Firefox rather than a fault in the process?


  5. Nice article! Here’s my two cents:

    Chrome is actually following the same rapid release schedule. But it makes the entire upgrade process invisible, and it doesn’t break your extensions. This results in great UX, and you never get any huge, jarring upgrades.

    In other words, like Nick said, this is an architecture/UX problem. The frequent upgrades should be fine in principle, Firefox just doesn’t seem to be executing very well.

    Firefox has been improving on the upgrade process a lot, so I have faith that they’ll get to the same kind of usability soon. (If they haven’t already – I haven’t checked in a while.)


  6. By the way, regarding the WebDriver issue, I like to run my tests in a Linux VM (with an xvfb or a headless tightvncserver), and it’s been working really well.

    Having a separate VM allows me to upgrade my day-to-day browser freely, while keeping the testing browser frozen inside the VM. I actually snapshot the VM before running “apt-get upgrade”, so I’m protected in case a Firefox upgrade breaks my Selenium tests.


  7. Jo, that’s exactly what I ended up doing: I made a Windows 7 VM in VirtualBox, and now my Firefox in there is wholly separate from my normal desktop browser. As well, I get benefits from not having any other programs running while I do web testing automation; the VM is totally dedicated to testing.


Comments are closed.