Straight talking 67

by Tim Anderson

Tim Anderson finds Microsoft’s Office frozen in time, and microservices not all they are cracked up to be.

HardCopy Issue: 67 | Published: November 6, 2015

Microsoft released Office 2016 in September. At first glance this is business as usual: we have had new Office releases every three years or so for over a decade, and this edition follows on from Office 2013, Office 2010, Office 2007 and Office 2003. However this time it’s a little different.
Office is important to developers for several reasons. One is that it remains, for the most part, the business standard, despite the efforts of the Document Foundation (the group behind Libre Office) and others to promote free alternatives and the ODF (OpenDocument Format) standard. This makes it important to developers who find themselves integrating applications with Office that generate documents for Word or Excel, or creating add-ins that implement custom features.

Office is also significant as a kind of statement of direction from Microsoft. Influential Windows design elements often appear first in Office, such as the Outlook 2003 sidebar, or the Office 2007 ribbon toolbars which are now seen in many applications including Windows Explorer (though they are still not universally popular). Office 2013 was in Microsoft’s ‘Metro’ design era and got all-caps menus and a content-first design, accounting for its washed-out appearance. Another example is the company’s championing of XML, which shows up in Office most notably in the Office Open XML file formats also introduced in 2007, but also in products like Office InfoPath, introduced in 2003 and now deprecated.

Microservice tradeoffs

“SOA [Service Oriented Architecture] gives way to Micro Services Everywhere” states an anonymous paper from Apigee, a US company specialising in API management and predictive analytics. The reasons it gives include difficulty in scaling “heavyweight application server architectures”, such as those built on WebSphere or WebLogic, and locating complex applications in a single container as creating a central point of failure.

Microservices describes an architectural style where applications are decomposed into multiple services that are independently deployed. This approach is often used in conjunction with containerisation, using tools such as Docker, so that they are isolated and the risk of dependency issues is minimised.

An API company has obvious reasons to promote a style that suits its own services, but the fact that it does so shows the extent to which microservices have become one of today’s buzzwords (along with DevOps and containers) for developers in tune with the latest techniques.

The benefits are real, according to Martin Fowler at development company ThoughtWorks, but he also warns of the risks in his article ‘Microservice trade-offs’. Microservices are ideal for large teams, since a small group of developers can focus on one piece of the application with considerable freedom in how it is implemented, so it can be optimised for its particular purpose.

But a moment’s thought reveals the drawbacks of this approach. It is not really simpler than a single application since you have merely exchanged the complexity of managing components in a single code base with the complexity of a distributed system. “Distributed systems are harder to program, since remote calls are slow and are always at risk of failure,” says Fowler.

This may seem surprising, given that ThoughtWorks has been something of a champion for microservices in the past, but it is common sense. Fowler’s summary is that “Microservices impose a cost on productivity that can only be made up for in more complex systems. So if you can manage your system’s complexity with a monolithic architecture then you shouldn’t be using microservices.”

That does not mean microservices are bad. However what it does mean is that only a subset of applications and organisations will benefit: a timely reminder that blindly following fashion in software development is never a good thing.

The direction Microsoft is taking with Office 2016 is instructive. There is so little new that Microsoft, in its publicly posted marketing list of What’s New, was in some cases reduced to referring to features that are new “if you upgrade from Office 2010”, or in other words, not new at all. Other items apply only if you use Office 365, such as Outlook 2016 Groups and the Clutter folder for low-priority messages, or only work with Office 365 or OneDrive, such as real-time co-authoring in Word.

The biggest change most users will see in Office 2016 is the return to lower case menus and a more colourful ribbon as Microsoft retreats from the Metro design concept. Yes, Excel has some nice new chart types and an improved PivotTable, tablet users get an ink-to-math Equation editor, and there is a “Tell me what you want to do” command search feature in some applications, but these are hardly major innovations.

If you enable the Developer ribbon in Word, for example, you will see a ribbon identical to that in Office 2013, save for the introduction of an Add-ins button that takes you to the Office Store, which is not itself new. Click the Visual Basic button and you are right back in the Visual Basic 6.0 era, and will have to remember everything you have forgotten about using the Set statement to assign object references, and when you should or should not use parentheses around arguments passed to functions.

The Office applications are mature of course, but it would be wrong to state that they are not capable of improvement. There is cruft in these old applications, and there are changes users would like to see, such as better handling of paragraph styles in Word, or usability improvements in Outlook and fixes for formatting issues in its email editor, which is in constant use by millions, to mention two examples.

As for Visual Basic for Applications, the developer perspective on this is mixed. Of course Microsoft has VSTO (Visual Studio Tools for Office) which lets you develop in VB.NET or C#, though because VBA is built on COM and runs within the application it tends to perform better than VSTO which relies heavily on COM interop. Excel developers report that the open source Excel-DNA project performs better than VSTO. However the chances of Microsoft putting effort into improving the Office developer story on Windows now look slim as it focuses on Apps for Office, which is about integrating web applications with Office, rather than extending the local application.

There is a positive side to having Office and VBA to some extent frozen in time, which is that custom solutions built on these technologies should continue to work. Microsoft’s support system means that because VBA is part of the current version of Office, it will be supported long into the future, despite being built on code from the Nineties.

The arrival of a new version of Office with only light changes does not mean that the Office team has been idle. On the contrary, it has delivered a large number of new products over the last couple of years, of which the highlight must be Office for iPad, released in March 2014 and regularly updated since. It was followed by versions for iPhone and Android, as well as Office Mobile for Windows 10 and Windows Mobile 10). In addition, Office 2016 for the Mac appeared in July 2015, and is closer to its Windows counterpart than Office 2011, though the implementation of VBA remains inferior.

Office 2016 screenshot

Microsoft’s shiny new Office remains, in some ways, frozen in time.

Microsoft’s investment in Office 365, and the increasing number of Office 2016 features that depend on it, is also relevant. Although Office 2016 looks increasingly like legacy as a developer platform, that is not true of Office 365 and the closely related Azure Active Directory, used by all Office 365 logins and available for developers to use in their own applications.

The problem with developing a solution based on desktop Office 2016 is that it will only ever run on Windows and perhaps (with some effort) on Mac, whereas building on Office 365 and creating cloud-based productivity solutions can be used from any platform. Microsoft itself appears to be focusing on that for its future, so for developers integrating with Office the message seems to be either to adapt to a cloud-based, cross-platform solution built around Office 365, or live with the current tools in Office 2016.