Complexity and Strategy by Terry Crowley, Former Microsoft Office Lead

Terry Crowley, a Microsoft engineer who lead Office development for over the last decade, reflects on the complexity of building software: from planning releases to technical strategy to dealing with market competition. There were two parts that stuck out to me I wanted to note:

First, he comments on how Google came into the "office productivity" space and applied pressure to what Microsoft was doing by having a suite of tools purely in the browser, available to any platform with an OS. Though he thinks it's too early to see how this will all play out, he does believe the complexity Microsoft has endured in building native Office tools (as opposed to Google's web-based tools) may end benefiting them. Googles apps can't compete in terms of functionality and features because building software as rich as Office in the browser just isn't feasible.

the performance challenges with running large amounts of code or large data models in the browser and managing the high relative latency between the front and back end of your application generally make it harder to build complex applications in a web-based environment. Hyper-ventilation by journalists and analysts about the pace of Google App’s innovation generally ignored the fact that the applications remained relatively simple...I knew the pace of innovation that was possible when functionality was still relatively low ...and nothing I saw as Google Apps evolved challenged that.

In the end, the complexity of the Office software suite ends up acting as a “moat” against the attacks of competitors that simply can’t be crossed without the years of experience Microsoft has gained building this kind of software.

Competitive strategy argues that when a competitor attempts to differentiate you need to focus on neutralizing that differentiation as quickly as possible... It is clear the Office apps would not be positioned functionally the way they are now (with fully compatible native and web clients on all devices and support for offline and co-editing) if there had been any squeamishness about embracing the challenges of complexity. That complexity (as it embodies valued functionality) is the moat.

It’s interesting to think of this complexity, rather than being an liability to the business, when viewed and handled correctly, being an asset and competitive advantage.

Number two:

The dynamic you see with especially long-lived code bases like Office is that the amount of framework code becomes dominated over time by the amount of application code and in fact frameworks over time get absorbed into the overall code base. The framework typically fails to evolve along the path required by the product — which leads to the general advice “you ship it, you own it”. This means that you eventually pay for all that code that lifted your initial productivity. So “free code” tends to be “free as in puppy” rather than “free as in beer”.

I find that a very interesting long-term observation on leveraging frameworks in your codebase. You always see the benefits up front. But in the long run frameworks are “free as in puppy”: once the initial joy has subsided they leave you with responsibility.