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.

RFC 6585 – Additional HTTP Status Codes

If you’ve missed it like I did, RFC 6885 has been published recently.  It introduces four additional status codes for the HTTP protocol.  The codes are:

  • 428 Precondition Required
  • 429 Too Many Requests
  • 431 Request Header Fields Too Large
  • 511 Network Authentication Required

Here is a blog post that gives a nice summary of purpose for each of the new status codes.

Karma-based pricing models for games

Slashdot links to an interview with Gabe Newell, of the Valve fame.  I think this idea is pretty interesting:

The issue that we’re struggling with quite a bit is something I’ve kind of talked about before, which is: how do you properly value people’s contributions to a community? … An example is – and this is something as an industry we should be doing better – is charging customers based on how much fun they are to play with. … “So, in practice, a really likable person in our community should get DOTA 2 for free, because of past behavior in Team Fortress 2. Now, a real jerk that annoys everyone, they can still play, but a game is full price and they have to pay an extra hundred dollars if they want voice.’

Karma-based systems aren’t the easiest ones to figure out.  But they have plenty of potential.  Given enough will, effort, and tweaking, I think this can be done.  How well it will actually work – remains to be seen.

The python of PHP bashing …

Apologies for a somewhat misleading title.  I just thought it was funny and appropriate.  This post is nothing but a link to yet another blog post discussing all things broken in PHP.  Or is it?

Virtually every feature in PHP is broken somehow. The language, the framework, the ecosystem, are all just bad. And I can’t even point out any single damning thing, because the damage is so systemic. Every time I try to compile a list of PHP gripes, I get stuck in this depth-first search discovering more and more appalling trivia.

I’ve been there, done that.  I’ve posted a few times on this blog and elsewhere my “appreciation” towards PHP.  I am one of those who doesn’t like the language.  Yet, I am one of those who programs pretty much entirely in PHP to the extent of completely forgetting all the other languages I once knew and used (hi, perl!).

Indeed, PHP has a number of shortcomings – it is inconsistent, unpredictable, unstable, and probably even insecure.  That’s all well known.  It’s a pain to use and even with that, it’s pretty much a de facto standard for web development these days.

As a working programmer I often hate and despise it.  Yet, as a technology guy and a big fan of the web, I love it.  With all its cons and ugly side effects, it did accomplish something.  It brought a lot of people into web development.  And those people have created a whole lot of cool things, which they otherwise couldn’t.  This feeling of remote appreciation is similar to my feeling of appreciation for Microsoft Windows and a bunch of related programs.  As “broken” as they were, they helped to bring a lot of people into computers.  Some of those people learned better ways.  Some brought the money that the industry always needs to grow and push the limits.  Some just provided an inspiration for others to solve certain problems.

Regardless, of whether you like PHP or not, if you are using it, you should know the downsides.  And for that the article above is a really good source.