The recent Ars Technica article "How Microsoft dragged its development practices into the 21st century" gave a good insight into how development methodologies are evolving in some groups in Redmond. The old carefully-paced world of software engineering worked well at a time when everyone accepted that it took time to design, program, test, and ship good (hopefully) software. It is a different matter today when any self-respecting web site is deemed static and perhaps even stagnant if it is the same from one week to the next.
Google can be blamed for establishing the trend towards ever-changing software. Or they can be commended for liberating us from the shackles of traditional ship discipline. No matter how you view the issue, there’s no doubt that Google demonstrated how it was possible to keep a product like Gmail under constant development while still delivering a great email service to end users. It’s true that Gmail was in what seemed to be perpetual beta for a very long time but that doesn’t take away from the achievement of building a service depended on by tens of millions of users while the software was constantly changing.
Of course, the exception of yesterday is the norm of today. What Google started in 2004 with Gmail is a path followed by almost all web sites today. And in fact, Google wasn’t the first because Amazon evolved quickly from its introduction and continues to add features at pace today.
Gmail is a better example for the discussion here because it’s the major competitor for Office 365. I think that the success of Gmail and the way that users accepted that features could appear and disappear without warning was a real shock to the program managers who chart out product development at Microsoft. It’s true that the lack of an installed base made it easy for Google to push out new features into Gmail but that aspect disappeared after people started to sign up for Gmail accounts in droves.
Microsoft originally attempted to use the fluid state of Gmail as a competitive weapon and pointed out how difficult such a fast-changing environment was to support. That’s true, but much of the support load has now been transitioned to cloud providers and anyway, the workers of today are much more accepting of fast product evolution than their predecessors, even if the introduction of the ribbon in Office 2007 caused a major fuss.
So Microsoft had to change its software development philosophy and methodology. The first evidence of change in the world of Exchange came when Rajesh Jha published details of the new development cadence in an EHLO blog post in August 2011. Since then we have become accustomed to frequent updates and have learned to deal with the quarterly servicing model introduced for Exchange 2013. After some initial quality hiccups, it seems like things are settling down and Exchange 2013 SP1 and Exchange 2013 CU5 have both appeared without too much trauma, albeit each having their own quirks that need to be found and understood before deployment into production.
The on-premises model is just a reflection of what happens inside Office 365. One mantra echoed at MEC was that “the future of Exchange is seen in Office 365”, justified because Office 365 always runs code that is several weeks ahead of what Microsoft makes available to on-premises customers through the quarterly cumulative updates. That is, until they decide to ship features in Office 365 like “Clutter” that will not appear in on an on-premises version anytime soon.
Office 365 is a massive multi-tenant environment so effective change management is a very big deal, especially when introducing new features. Microsoft recently announced some modifications in the way that they make customers aware of upcoming change, all of which seem to be pretty logical and appropriate. It's true that some changes still surface without warning but the basic notion of laying out a roadmap to inform customers when to expect change is good.
Even so, some will question why change has to occur so rapidly. The answer is that Microsoft has to respond to industry trends where rapid, iterative releases that push out new features to gather user reaction and feedback is the new basis for product development. Part of this is because it keeps products fresh, interesting, and ahead of competitors, part because it maintains excitement (created by marketing) around products. It’s the way of the web.
I have some sympathy to the complexity that software engineers working on Office 365 and other cloud services have to cope with today. The challenge of working at scale where every error is magnified several million times if found by users is mind-boggling, as is the debugging effort required when tens of terabytes of data might have to be analyzed to look for clues as to why software doesn't work as designed (this blog post from Facebook explains how they fixed a problem for their iOS client).
To gain a better insight into the current software engineering trends, you could do worse than spend 15 minutes or so over a cup of coffee to review a short video about Spotify’s engineering culture. It’s a world removed from the measured approach taken by corporate software engineering at Digital Equipment Corporation that I knew in the 1980s and 1990s. And it’s very different to the way that Microsoft built products in the past. But it’s what consumers expect and want today. Instant fulfilment, new gizmos to play with, excitement. All delivered by software.
Waterfall or agile, scrums and sprints are all very well, but rushing software out without sufficient testing is not a good thing. We've seen too many problems that seem to be related to insufficient testing (or rush to ship?), the latest being yesterday's fiasco when it was discovered that an Outlook update to fix incorrect holiday dates and bad translations for several languages meant that users could not access archive mailboxes. Speed is all very well, but quality is so much more important.
Follow Tony @12Knocksinna