Rapid releases killed Firefox’s reputation

Via this LWN post I came across a very insightful blog post by Brian Jono, one of those many people who develop Mozilla Firefox.  In his blog post Brian talks about Firefox’s rapid release cycle and how it drove a lot of people to Google Chrome.  There’s nothing new to that.  But Brian’s post is a must read for anyone involved in software development – there are several lessons to learn.  Here are a few bits that I found interesting.

On updates in general:

I’ve been thinking a lot about the fundamental disconnect between the developers and the users. I think it comes down to: Software developers have a perverse habit of thinking of updates/new releases as a good thing.

It’s hard to convince a software developer otherwise: their salary depends on outputting a constant stream of updates, so of course they think updates are good.I used to believe it. Only after I heard from dozens of different users that the rapid release process had ruined Firefox did I finally get it through my thick skull: releasing an update is practically an act of aggression against your users. The developer perspective is “You guys are going to love this new update we’ve been working on!” The user perspective is “Oh god here comes another update, is there any way I can postpone the agony for a few more days?”

On changes to the user interface (UI):

So many companies release updates which radically change the interface for no significant gain — they seem to be moving sideways rather than forward, changing things around for the sake of change. Maybe their UI designers are bored and need to do something to justify their jobs, I don’t know. After years of aspiring to improve software usability, I’ve come to the extremely humbling realization athat the single best thing most companies could do to improve usability is to stop changing the UI so often! Let it remain stable long enough for us to learn it and get good at it. There’s no UI better than one you already know, and no UI worse than one you thought you knew but now have to relearn.

On competition-driven development:

I have another theory, too: When software companies get to a certain size, they start taking their users for granted. They start treating their users as pawns in a battle against some other company. Faceless millions. Gotta copy everything the other company does, or risk falling behind. So they end up doing everything the other company does whether the users want it or not, and probably doing a crappy job to boot.

On user loyalty:

Software companies would do well to learn this lesson: anything with the phrase “users love our product” in it isn’t a strategy, it’s wishful thinking. Your users do not “love” your software. Your users are temporarily tolerating your software because it’s the least horribleoption they have — for now — to meet some need. Developers have an emotional connection to the project; users don’t.

All software sucks. Users would be a lot happier if they had to use a lot less of it. They may be putting up with yours for now, but assume they will ditch you the moment something 1% better comes along — or the moment you make your product 1% worse.

There’s more.  Just read the whole thing, it’s well worth it.