Technology tends to speed up everything. Mostly this is good…but sometimes not so much.
Smartphones, for example are one of the greatest thing invented, providing consumers with tremendous added convenience, productivity and mobility as well as greatly increased our ability to multitask.
But there are often unintended consequences that come with otherwise fantastic technological advances. Using the same smartphone example, the added ability to multi-task has also enabled scenarios most of us probably would like to do without: the person loudly talking on their mobile phone while holding up the grocery checkout line, checking email and texts at every stoplight (apparently now mandatory), or worst of all texting on their smartphone while driving.
In much the same way SaaS freed both business users and consumers from much of the mundane and sometimes time-consuming activities of installing and maintaining software. For software companies themselves, it’s freed them from much of the complexity of distributing, updating and maintaining their software across a wide range of geographies and heterogeneous operating environments. Creating and distributing a new version is as simple as updating the application on their host, which they’ve chosen themselves and well understand the vagaries. SaaS is revolutionizing many segments of the software business and represents an inflection point in software development and marketing. There’s no arguing that the SaaS trend overall represents a true step forward in ease-of-use and productivity for users.
But back to that unintended consequences thing…..
Because Developers can so easily push a new software version out into the marketplace–they often do–and it seems with increasing frequency and velocity. I’ve personally experienced some troubling issues that I attribute to this practice.
A few examples of unintended consequences
Linkedin, Google Analytics and Google Adwords are 3 widely used examples where I’ve seen problems. Google Gmail is another. These applications are characterized by continuous changes to interfaces which has degraded what was initially easy-to-use applications. With the fast addition of features, documentation often doesn’t keep up and is either out-of-date or missing completely. Probably most importantly, because you can “change everyone immediately” it appears that a side effect of speed is testing rigor that has suffered relative to the old “major release cycle”, where things had BETTER be right prior to that expensive new version roll out.
I’ve experienced many bugs recently with Google Adwords in particular, which as become a VERY capable (and complex product). With Linkedin I’ve also experienced an increasing number of issues including many existing, important features once working perfectly well, which were “broken” by attempts to make them better or changes to code around them. A recent example was a problem with redirection of articles and other links(with anchor text) in the widely used group function. Overnight the redirection feature stopped working; clicking on any such link in a group discussion sent you to a “redirection loop” error message. This went on intermittently for two or three days as the programmers no doubt were scrambling to fix live code. Then for a day or two all the links no longer went to an error message, but to the “Linkedin Today” section of the site. Finally the problem was fixed. But how such a major bug made it into a live release is astounding to me–and it hasn’t been an isolated incident in any of these applications.
I don’t mean to pick on Linkedin or Google. I am a dedicated Linkdin user and believe that Google Analytics, Gmail and Google Adwords are great applications. But let’s face it, these aren’t exactly small companies where you might expect poor process, lack of resources or a rogue “cowboy” programmer to lead to these types of issues. To the contrary, they are exactly the opposite of that. I also don’t mean to indict the entire SaaS industry; there are a large number of companies that are not encountering these types of problems. But in my experience these issues are widespread, maybe even endemic in the SaaS industry–which is why I’m sounding the alarm.
Is Agile TOO agile?
I realize I risk getting pounded by zealot agile developers here, but I wonder if the parallel move toward agile software development (which conceptually fits very well with the SaaS model) is partially to blame. Again, I’m talking about unintended consequences here. Much like the trend to SaaS, the trend toward agile software development methodologies has been a very positive thing for the software business. Agile executed well is great for the software business. But I wonder if the very fact that agile encourages speed and somewhat less process rigidity hasn’t increased the risk of “cowboy release management” in environments that allow a little too much flexibility. And while the focus on quickly responding to customer needs is a great concept, it can’t mean adding every feature that is requested without thinking through the larger potential implications of killing ease-of-use due to a bloated, confusing product. I’m sure there will be a lot of disagreement with this–the details are probably best left to another discussion.
Users have lost control over stability
Don’t get me wrong, I’m not arguing to go back to the “good ol days” of the annual (or worse) release cycles of on-premise software. This definitely slowed innovation; it sometime seemed like it took FOREVER to get new software out into the market. But from a user perspective, even if the release was buggy, the bugs quickly became well-known and you could work around them or get support on them. So at least the level of “bugginess” was stable. And if you got a release that was very stable, you could choose to stay with it until a new release came along that you knew was also stable, or at least included new features that you just HAD to have. You could choose to upgrade WHEN YOU WERE READY. You could also get your staffed trained on the new release, test it out, etc. on your schedule. BEFORE it went into your important production work.
Today, there is much less little control for the user from a usability or stability point of view. New features (and BUGS!) in SaaS show up overnight. If you don’t use a SaaS application for a few months and it’s one that is being developed particularly actively, you might barely recognize it the next time you log in. I’m not exaggerating–it’s happened to me and it’s exasperating. This can take you from a highly productive expert user almost back to a novice in a blink of an eye.
Too Much of a Good thing
SaaS is great when done right–no one should argue that and I’m not. I’m simply recommending a little common sense–a bit of restraint. Fast to market is a GOOD thing. I believe in fast release cycles–It’s something I’ve bitched about my entire career in the software business. But if you slow down just a bit, the desirability of your application–and your brand strength in the marketplace will probably appreciate faster. Remember, the ultimate goal isn’t faster releases themselves, but to more quickly make the user’s life better and easier–and some of the current practices in the SaaS world aren’t supporting that achievement. Just because you can, doesn’t mean you should.
There you have it, my rant on some undesirable excesses in the SaaS business . Feel free to disagree– let us know what you think with a comment below.
Follow Phil Morettini and Morettini on Management via Twitter, Facebook, LinkedIn, RSS, or the PJM Consulting Quarterly Newsletter. Contact Phil directly at info@pjmconsult.com
Leave a Reply