“Software developers and users come from very different perspectives, software developers always see an update as a good thing. We’re biased, because we have an emotional attachment to our own work, towards thinking that the next update is going to be the greatest thing ever. I wish developers throughout the industry would recognize the cost that we inflict upon users because of our obsession with constant change.”
Jono Xia quoted in a Computerworld article “Ex-Mozilla worker rails against developers’ love of constant change, frequent updates” July 16, 2012. He was answering questions related to two blog posts
In “Everybody hates Firefox updates” he offers three reasons why users hate updates:
- The download/restart takes forever and interrupts your work with a bunch of intrusive dialog boxes.
- The update may break stuff that you counted on, either by removing features you were using, or by breaking compatibility with other software you use. Maybe the developers never tested your use case, or worse – they tested for it but decided it didn’t matter because only 2% of users used it. Tough luck to you if you’re one of those 2%.
- If they changed the interface, your productivity will be lower than usual until you’ve spent a bunch of time learning a new interface. Even if the new interface is “better”, in some theoretical way, to some hypothetical average user, re-training yourself to use it is nothing but a time sink.
It is almost as if SaaS vendors are mimicking the behavior of mainframe IT groups from the 1980’s:
- We can only support one system.
- We make upgrades when it is convenient for the system administrators.
- We don’t have time to plan for a rollback, it’s faster just to flash cut to the new system and continue patching and updating to fix the consequences.
The reality is that your customers have complex workflows that are not entirely under your control but dependent upon your software. Much has been made about the cost savings of supporting only one version but I think that is less important than the cost you can impose on customers with interface incompatibilities and forced updates. One model to consider is supporting at least three releases in parallel:
- old and reliable: the devil you know, but obviously with fewer features.
- current production version: more features and some bugs
- new or beta: more features and more bugs
Also develop the capability to roll back a change if it’s clear in the first 48 hours that there are serious problems. With on premises software your customers will take this upon themselves to run several versions in parallel, but SaaS offerings for business customers need to consider allowing concurrent version in use at the same customer. This allows you to tell when a new feature is actually useful because customers choose to adopt it.
“Innovation is not what innovators do but what customers adopt.”
Trackback from your site.