Or more to the point, they are forcefully upgraded to it on day 1, so minimizing defect deferrals is really important. Well, isn't that always important, you might say. In general yes, of course it is, but Cloud and On-Premises business differs. A mode of cooperation has evolved in the on-premises business, where - for better or worse - releases numbered .0 [dot zero] are often not rolled out in enterprise production environments. It's not that we or other software vendors don't stand behind, or thoroughly test, our .0 releases. But many of our enterprise customers want to get their hands on the new functionality in the latest release, so they can set it up in a trial environment internally and start becoming familiar with it. They inherently, though rarely explicitly, accept that while we obviously run the full regression test suites against .0 releases, usage patterns for the new functionality may not be fully known yet before the software ships, and so test coverage may leave gaps, especially in areas of unforeseen configurations and usage. Early use in trial environments allows identification of problematic configurations, which in turn allows us to harden the code by fixing issues in the .1 [dot one] maintenance release. Some would say this should happen via beta testing prior to release, and it does to some extent, but the full trial coverage doesn't happen until we put the .0 release out. Customers using the software in a standard configuration with traditional usage patters are normally fine with the .0 release. More [IT] innovative enterprises, who push the envelope with unique configurations and usage patterns that leverage the newest functionality are where we find the most .0 defects. As a quality engineer, I strive constantly to improve the development and test processes to reduce defect rates, but I'm not blind to the symbiosis with innovative enterprises in play here for On-Premises environments.
In the Cloud space, the issue of defects in a first release of new function takes on a different level of importance, for at least two major reasons. First, all users upgrade on the same day. It's not just the innovative bleeding edge customers, who are willing to encounter and resolve issues to engage with new function early, who adopt the release. It is everybody. Including lots and lots of users with lesser software skills than the bleeding edge experimenters. It really requires a different mind set. Average users need rock solid reliability to do their day job. They perhaps care less about new functionality, but they care much, much deeper about reliability than the experimenters do. Many Cloud providers, including us, have a legacy background in offering on-premises software products, and for those, this is a difference. We need to take to heart that the old balance doesn't apply any more. Release criteria need to be tighter. Defect deferrals fewer. Test coverage wider.
Some Cloud vendors allow multiple releases to be in production simultaneously, but that is not the case for our offerings (LotusLive, SmartCloud).
PS: The blond character above is 'Fletcher', whom I have recruited to illustrate several of the Cloud differences in this intended series. Fletcher is my avatar in an internal comic strip used occasionally in our corner of IBM. I am grateful to my creative colleague, Jennifer Kelley, for coming up with Fletcher.