Commentary on Complexity And Strategy by Terry Crowley
new functionality gets harder to add as a system gets more functional.
advocates for these new technologies tended to confuse the productivity benefits of working on a small code base (small N essential complexity due to fewer feature interactions and small N cost for features that scale with size of codebase) with the benefits of the new technology itself — efforts using a new technology inherently start small so the benefits get conflated.
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
Productivity advantage of borrowed technology, frameworks, languages are demonstrated on simple projects but often fail to translate into long term benefits on a complex product. They may contribute to add accidental complexity later on as they fail to evolve with the product.
Unfortunately, Preview view ended up being a gift that kept on giving. The complexity it introduced had nothing to do with any failure in the initial programming of the feature. The challenges were that as we added new functionality, Preview required special consideration — additional specification — about how it should behave and interact with these new features. Frameset support (an early HTML feature that has fallen into disuse) was especially complex.
One thing that was clear to us was that the cloud/browser development strategy did not offer a breakthrough in the constraints of essential complexity like I am discussing here. In fact, 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.
Certain types of features (here running distributed over the browser) impede on the long term capability to deliver new features, so much so that the product cannot grow anymore in terms of its essential complexity.
These features tend to be connected heavily to all other components.
file formats continued to serve as a critical competitive moat with immensely strong network effects
Bill wanted (still wants) a breakthrough in how we build rich productivity apps. He expected that the shape of that breakthrough would be to build a highly functional component that would serve as the core engine for all the applications. That model leads you to invest in building a more and more functional component that represents more and more of the overall application (and therefore results in more of the cost of building each application being shared across all applications). This view that I have described here of increasing feature interaction causing increasing essential complexity leads to the conclusion that such a component would end up suffering from the union of all the complexity and constraints of the masters it needs to serve. Ultimately it collapses of its own weight.
File formats are key to allow creation of ecosystem of simpler apps, and neutralizing competitive threats. Data reuse is superior to code reuse in terms of allowing isolation of complexity through the creation of simpler, more focused products.