Complexity and Strategy 复杂性与战略

I struggled with how to think about complexity through much of my career, especially during the ten years I spent leading Office development. Modeling complexity impacted how we planned major releases, our technical strategy as we moved to new platforms, how we thought about the impact of new technologies, how we competed with Google Apps, how we thought about open source and throughout “frank and open” discussions with Bill Gates on our long term technical strategy for building the Office applications.
在我职业生涯的大部分时间里，尤其是在领导 Office 开发的十年间，我一直在为如何考虑复杂性而挣扎。复杂性建模影响了我们如何规划主要版本、我们在转向新平台时的技术战略、我们如何考虑新技术的影响、我们如何与 Google Apps 竞争、我们如何考虑开源，以及我们与比尔-盖茨就构建 Office 应用程序的长期技术战略进行的 "坦诚而公开 "的讨论。

I want to explore the issues I faced then and how our approach was influenced by how I thought about complexity.
我想探讨我当时面临的问题，以及我们的方法如何受到我对复杂性的思考的影响。

I’m currently rereading Melanie Mitchell’s “Complexity: A Guided Tour” and am heartened that even professional academics who study complexity full time have a hard time defining or measuring it. No breakthroughs here, I’m afraid, but let us try to construct a mental model that we can use to explore the topic.
我目前正在重读梅兰妮-米切尔（Melanie Mitchell）的《复杂性导览》（Complexity：导读》一书，并欣慰地发现，即使是全职研究复杂性的专业学者，也很难定义或衡量复杂性。这里恐怕没有什么突破性的进展，但让我们试着构建一个心智模型，用来探讨这个话题。

When we think about enhancing a software system, we can consider the curve that measures aggregate functionality against the aggregate cost required to achieve it. My impression from reading journalists and analysts writing about software is that they believe you have a linear curve that generally looks like this:
当我们考虑如何增强软件系统时，可以考虑用一条曲线来衡量总体功能与实现该功能所需的总体成本。通过阅读记者和分析师撰写的有关软件的文章，我的印象是，他们认为你有一条线性曲线，一般看起来是这样的：

This reflects a curve where the incremental cost of new functionality is relatively consistent over time as the product grows more capable. Could some breakthrough new technology or development strategy lift that curve up or improve its slope?
这反映了这样一条曲线：随着产品功能的不断增强，新功能的增量成本随着时间的推移而相对稳定。一些突破性的新技术或开发战略能否提升或改善这条曲线的斜率？

Alternatively, the curve might look concave (also possibly changed in slope or translated up by some new technical strategy).
或者，曲线看起来可能是凹形的（也可能是斜率发生了变化，或者是通过某种新的技术策略转化而来）。

This reflects a curve where new functionality gets easier to add over time, perhaps because you develop more and more infrastructure, expertise, process and tooling that makes adding new features more and more efficient.
这反映了一条曲线，随着时间的推移，新功能的添加会变得越来越容易，也许是因为你开发了越来越多的基础设施、专业知识、流程和工具，使得添加新功能的效率越来越高。

People who have worked in software for a long time tend to believe the curve actually looks convex, more like this:
长期从事软件工作的人倾向于认为，曲线实际上看起来是凸的，更像这样：

This reflects a model where new functionality gets harder to add as a system gets more functional.
这反映了一种模式，即系统功能越多，新功能就越难添加。

So which curve reflects reality and how does it impact strategy?
那么，哪条曲线反映了现实，它又如何影响战略？

As you might expect, it depends, but that final dismal curve probably captures the reality for large systems best. Let’s walk through a few examples.
正如您所预料的那样，这取决于具体情况，但最后那条令人沮丧的曲线可能最能反映大型系统的实际情况。让我们举几个例子。

The FrontPage editor had key well-factored components like the lexical analyzer, HTML parser as well as core infrastructure built into the model and view that made it relatively straight-forward to extend the editor to support new HTML tags as the HTML standard evolved. The lexer and parser were driven from tables that described how classes of tags were handled so new tags simply required another entry in the table. Typically there was a small amount of custom rendering work and then whatever custom editing support was needed — typically just a relatively simple dialog to edit any special tag properties. The editor model automatically handled multi-level undo, redisplay, load and save. As we added support for certain features like parsing of server-side scripting languages like ASP, that support could be easily extended to also support other languages like PHP. It was clear that the powerful infrastructure we had built made adding certain types of new features much easier — resulting in something that looked like that concave curve above for many features.
FrontPage 编辑器的关键组件，如词法分析器、HTML 解析器以及内置在模型和视图中的核心基础架构，都是经过精心设计的，因此随着 HTML 标准的发展，扩展编辑器以支持新的 HTML 标记也就相对简单了。词法分析器和解析器由描述如何处理标签类别的表格驱动，因此新标签只需在表格中添加一个条目即可。通常情况下，只需进行少量的自定义渲染工作，然后就能获得所需的自定义编辑支持--通常只是一个相对简单的对话框，用于编辑任何特殊的标签属性。编辑器模型可自动处理多级撤销、重新显示、加载和保存。随着我们增加了对某些功能的支持，如对 ASP 等服务器端脚本语言的解析，这种支持可以很容易地扩展到对 PHP 等其他语言的支持。很明显，我们所构建的强大基础架构使得添加某些类型的新功能变得更加容易--这使得许多功能看起来就像上面的凹形曲线。

The FrontPage editor also offered a good counter-example to this rosy picture. The editor supported three different views for an HTML page that was loaded in the editor: “Normal” view was the typical WYSIWYG view used for editing, “HTML” showed a color-coded editable view of the underlying HTML tags and “Preview” showed the page in an embedded instance of Internet Explorer. Preview view was especially useful for verifying layout and testing dynamic behavior in the browser. Preview view had been an “overnight feature” that was added in a burst of programming by one of our developers who was a wizard with ActiveX programming and was also able to leverage the infrastructure we had already built to support independent views on the same document for Normal and HTML view.
FrontPage 编辑器也提供了一个很好的反面例子。对于加载到编辑器中的 HTML 页面，编辑器支持三种不同的视图："正常 "视图是典型的所见即所得视图，用于编辑；"HTML "视图显示底层 HTML 标记的彩色编码可编辑视图；"预览 "视图在嵌入的 Internet Explorer 实例中显示页面。预览视图对于在浏览器中验证布局和测试动态行为特别有用。预览视图是一个 "隔夜功能"，是由我们的一位开发人员在编程过程中突然添加的，他是 ActiveX 编程方面的专家，也能够利用我们已经建立的基础架构来支持同一文档上的普通视图和 HTML 视图的独立视图。

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. As we added new support for server-side scripting and especially more and more support for editing SharePoint-based webs, we continually ran into questions about how Preview should work and then additional programming effort to implement that behavior. Eventually (especially as SharePoint and dynamic site support became more of a product focus) the team just removed the feature entirely. This was clearly a feature that turned that curve convex, making everything new harder to implement. Again, the problem was not because of poor design, the problem was that it interacted with many of the other features we were working on and required additional specification and additional code to implement that specification.
不幸的是，"预览视图 "最终成为了一个不断送出的礼物。预览视图带来的复杂性与该功能最初的编程失败毫无关系。我们所面临的挑战是，随着新功能的增加，预览视图需要特别的考虑--额外的规范--来确定它的行为方式以及与这些新功能的交互方式。框架集支持（一种早期的 HTML 功能，现已废弃不用）尤其复杂。随着我们增加了对服务器端脚本的新支持，尤其是对基于 SharePoint 的网页编辑的支持越来越多，我们不断遇到关于预览版应该如何工作的问题，然后需要额外的编程工作来实现这些行为。最终（尤其是当 SharePoint 和动态网站支持成为产品的重点时），团队干脆完全删除了该功能。很明显，这个功能将曲线变凸，使得所有新功能的实现都变得更加困难。同样，问题并不在于设计不佳，而在于它与我们正在开发的许多其他功能相互影响，需要额外的规范和额外的代码来实现这些规范。

Word offered another interesting example. When I moved to lead the Word development team for the Office 2007 product cycle, we were working with PowerPoint on enhancing visual support for tables. PowerPoint had done early prototyping of features that leveraged improving graphics support, including gradients, transparency, shadows and reflection. This early prototyping work led them to have a good grasp on how expensive these features would be to implement. They were pushing to get these features adopted consistently across the Office suite. Feature consistency helps users transfer learning between applications and improves visual and semantic consistency as content is copied and pasted between the applications.
Word 提供了另一个有趣的例子。当我调任 Office 2007 产品周期的 Word 开发团队负责人时，我们正与 PowerPoint 合作增强对表格的可视化支持。PowerPoint 已经完成了利用改进图形支持的功能的早期原型开发，包括渐变、透明、阴影和反射。早期的原型设计工作使他们很好地掌握了这些功能的实施成本。他们正在努力使这些功能在 Office 套件中得到一致采用。功能的一致性可以帮助用户在不同的应用程序之间转移学习内容，并在应用程序之间复制和粘贴内容时提高视觉和语义的一致性。

When the Word team went to estimate the cost of these features, they came back with estimates that were many times larger than PowerPoint’s estimates. Some of this cost was because the PowerPoint code architecture was better structured to add these types of visual features. But the bulk of the growth in estimates was because Word’s feature set interacted in ways that made the specification (and hence the implementation) more complex and more costly. How would the feature interact with spanning rows and spanning columns? How about running table headers? How should it show up in style sheets? How do you encode it for earlier versions of Word? What about all the different clipboard and output formats that Word supports — how should these features appear there? In Fred Brooks’ terms, this was essential complexity, not accidental complexity. Features interact — intentionally — and that makes the cost of implementing the N+1 feature closer to N than 1.
当 Word 团队去估算这些功能的成本时，他们得出的估算结果要比 PowerPoint 的估算结果大很多倍。其中部分成本是因为 PowerPoint 的代码架构更适合添加这些类型的可视化功能。但估算值增长的主要原因是，Word 功能集的交互方式使规范（以及实施）变得更加复杂，成本也更高。该功能如何与跨行和跨列交互？运行表头如何？如何在样式表中显示？如何为早期版本的 Word 进行编码？Word 支持的各种剪贴板和输出格式又是怎样的？用弗雷德-布鲁克斯（Fred Brooks）的话来说，这是基本的复杂性，而不是偶然的复杂性。功能之间会有意无意地相互作用，这使得实现 N+1 功能的成本更接近于 N，而不是 1。

This view that costs scale with feature depth because of growth in essential complexity leads to a great emphasis in continuously improving and refactoring the code base. If essential complexity growth is inevitable, you want to do everything you can to reduce ongoing accidental or unnecessary complexity. Of course, the difference between accidental and essential complexity is not always so clear when you are embedded in the middle of the project and to some extent is determined by the future evolution of the product. So it is “more guideline than rule” — internally we would talk about “20% for art”.
这种观点认为，由于基本复杂性的增长，成本会随着功能深度的增加而增加，因此要高度重视持续改进和重构代码库。如果基本复杂性的增长是不可避免的，那么就需要尽一切可能减少意外或不必要的复杂性。当然，当你置身于项目中间时，意外复杂性和基本复杂性之间的区别并不总是那么明显，而且在某种程度上还取决于产品的未来发展。因此，这 "更多的是指导方针，而不是规则"--在内部，我们称之为 "艺术的 20%"。

When we started the OneNote project (first shipped in Office 2002), we seriously considered whether to build it on top of the very rich Word editing surface. The OneNote team eventually decided to “walk away” from Word’s complexity (and rich functionality) because they believed they needed to be free to innovate in a new direction without paying the cost of continually integrating with all Word’s existing functionality. They would settle for a much smaller initial “N” in order to be able to innovate in a new direction. That is a decision the team never regretted. They were able to innovate in storage model, sharing and a different overall content model with a relatively small team because they had full control of their end-to-end stack.
当我们开始 OneNote 项目（在 Office 2002 中首次发布）时，我们曾认真考虑过是否要将其构建在功能非常丰富的 Word 编辑界面之上。OneNote 团队最终决定 "放弃 "Word 的复杂性（和丰富的功能），因为他们认为他们需要自由地向新的方向创新，而不需要支付不断集成 Word 所有现有功能的成本。为了能够在新的方向上进行创新，他们愿意接受小得多的初始 "N"。这是团队从未后悔过的决定。由于他们能够完全控制端到端的堆栈，因此他们能够以相对较小的团队在存储模式、共享和不同的整体内容模式方面进行创新。

Other “features” during this time period involved porting most of the Office suite to the 64-bit version of Windows and then later porting to ARM-based Windows (for Windows RT and later Windows Phone devices). The cost of this work scaled with the size of the code base (10’s of millions of lines of code) and added an ongoing multiplicative factor to our engineering system costs to support building, testing and shipping on these additional platforms. There were an ongoing number of these types of broad new product functionality that scaled with the size of the codebase. Security is first in line there and deserves a separate post, as does cross-platform.
在此期间的其他 "功能 "包括将大部分 Office 套件移植到 64 位版本的 Windows，随后又移植到基于 ARM 的 Windows（用于 Windows RT 和后来的 Windows Phone 设备）。这项工作的成本与代码库的规模（千万行代码）成正比，并给我们的工程系统成本增加了一个持续的乘数系数，以支持在这些额外平台上的构建、测试和交付。随着代码库规模的扩大，此类广泛的新产品功能也在不断增加。安全是第一位的，值得单独讨论，跨平台也是如此。

This perspective does cause one to turn a somewhat jaundiced eye towards claims of amazing breakthroughs with new technologies. Managed code was one that we argued about for a long time during this period. Leveraging open source also has some of the same dynamics. What I found is that 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. Additionally, these new technologies (Java, C#, NodeJS is the latest one) start out with a much more functional initial set of base libraries and rich frameworks, certainly compared to what we saw in C and C++ and in the early days of either Mac or Windows application development.
这种观点确实会让人对新技术取得惊人突破的说法产生一定的怀疑。在此期间，我们对托管代码争论了很长时间。利用开放源代码也有一些相同的动力。我发现，这些新技术的拥护者往往会将小代码库（由于功能交互较少，基本复杂度为 N 小，功能成本为 N 小，随代码库大小扩展）与新技术本身的优势混为一谈--使用新技术的工作本来就是从小规模开始的，因此两者的优势会被混为一谈。此外，这些新技术（Java、C#、NodeJS 是最新的技术）一开始就提供了功能性更强的初始基础库和丰富的框架，当然，这与我们在 C 和 C++ 以及 Mac 或 Windows 应用程序开发早期所看到的情况有所不同。

In terms of our Functionality/Cost curves, this means that you push that curve significantly up the functionality axis at the start. This can create confusion for technical managers about whether you have simply translated a curve that still has the same fundamental shape or whether you have changed something significant about the shape or slope of the curve itself. This is especially true in an environment where every disciple of a new technology is singing its praises to the heavens. In actual practice, if the product stays small, you can essentially “book” that initial productivity gain — a clear win. If the product starts to grow complex — and you can predict that fairly directly by looking at the size of the development team — then costs will come to be dominated by that increasing feature interaction and essential complexity. Project after project has demonstrated there is nothing about language or underlying technical infrastructure that changes that fundamental curve.
就我们的功能/成本曲线而言，这意味着在一开始就将该曲线的功能轴大幅推高。这可能会让技术经理们感到困惑，他们不知道你是简单地转换了一条基本形状不变的曲线，还是曲线本身的形状或斜率发生了重大变化。尤其是在新技术的每一个门徒都对新技术赞不绝口的环境中，这种情况更是如此。在实际操作中，如果产品规模不大，你基本上可以 "预订 "最初的生产率收益--这是一个明显的胜利。如果产品开始变得复杂--你可以通过观察开发团队的规模相当直接地预测到这一点--那么成本就会被不断增加的功能交互和基本复杂性所支配。一个又一个的项目证明，语言或底层技术基础架构都无法改变这一基本曲线。

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”.
像 Office 这样的长寿命代码库的动态变化是，随着时间的推移，框架代码的数量会被应用程序代码的数量所支配，事实上，随着时间的推移，框架会被吸收到整个代码库中。框架通常无法按照产品所需的路径发展--这就导致了 "你交付了它，你就拥有了它 "的普遍建议。这意味着，你最终要为那些提高了你初始生产力的代码买单。因此，"免费代码 "往往是 "小狗的免费"，而不是 "啤酒的免费"。

None of this argues against “lean startups” or “minimal viable products” or any of the other approaches that focus on accelerating the process of finding the right product/market fit or feature viability. Continuous agile delivery is a fundamental change in development process because it removes the horrendous friction and delay between feature development and feature use. (There are other benefits as well but again worth a separate post.) But continuous delivery does not change anything about the essential complexity I am discussing here except so far as it helps prevent the team from building features that increase complexity but do not add user value. The highest cost feature you can build is the one that is not used or valued — your cost / benefit ratio is infinite. You continue paying to integrate with that useless feature as you build every additional feature from that point forward.
这些都不是反对 "精益创业"、"最小化可行产品 "或任何其他专注于加快找到合适的产品/市场契合点或功能可行性的方法。持续敏捷交付是开发流程的根本性变革，因为它消除了功能开发与功能使用之间可怕的摩擦和延迟。(但持续交付并没有改变我在这里讨论的基本复杂性，除非它有助于防止团队构建那些增加复杂性但不增加用户价值的功能。你所能构建的成本最高的功能就是不被使用或不被重视的功能--你的成本/收益比是无限的。从那时起，你在构建每一个附加功能时，都要继续为集成这个无用的功能付费。

The Office competition with Google Apps was (and still is) strongly influenced by these perspectives on complexity. The Office team had made the decision to build web applications just prior to the time Google bought Writely (the original version of Google Docs). As we looked at that product, we were well positioned to understand the competitive strategy from a technical and feature perspective. After a fairly quiet period in the productivity space, new browser-based applications were launching in multiple product areas. Delivering through the browser combined a number of key breakthroughs, especially compared to the consumer PC application environment of the time. The browser brought deployment and acquisition friction close to zero. Storing your content in the cloud allowed access to your content anywhere which was key as multiple PC use exploded in work, home and school. Content in the cloud then enabled easy sharing and co-editing, including later real-time co-authoring with features like chat and change notifications. Browser-based application delivery solved the deployment problem which was a huge issue for PC applications in the days before app stores. This enabled continuous delivery of new features as well as ensuring that everyone was up-to-date with the latest version. Free or freemium business models facilitated low friction sharing enabled by this technical strategy.
Office 与 Google Apps 的竞争曾经（现在仍然）深受这些复杂性观点的影响。就在谷歌收购 Writely（谷歌文档的最初版本）之前，Office 团队就已经决定构建网络应用程序。在研究该产品时，我们很好地从技术和功能角度理解了竞争策略。在生产力领域经历了一段相当平静的时期后，多个产品领域都推出了基于浏览器的新应用。与当时的消费类 PC 应用程序环境相比，通过浏览器提供服务实现了一系列关键突破。浏览器使部署和获取的摩擦接近于零。将内容存储在云端，可以随时随地访问内容，这在工作、家庭和学校的多 PC 使用爆炸式增长的情况下非常关键。然后，云中的内容可以方便地共享和共同编辑，包括以后使用聊天和更改通知等功能进行实时共同创作。基于浏览器的应用程序交付解决了部署问题，在应用程序商店尚未出现的时代，这对 PC 应用程序来说是一个巨大的问题。这样就能持续交付新功能，并确保每个人都能获得最新版本。免费或免费商业模式促进了这一技术战略所带来的低摩擦共享。

In fact, one of the hardest aspects of responding to this competition was navigating the business model change from device-based licensing to a user subscription model that enabled a single user to stay up to date on the latest versions of Office on all their devices. Anyone that follows the tales of disruption in the technology industry is well-attuned to the fact that asymmetric business model attacks enabled by new technology advances is one of the most effective strategies a competitor can take.
事实上，应对这种竞争最困难的方面之一，是引导商业模式从基于设备的许可转变为用户订阅模式，使单个用户能够在其所有设备上使用最新版本的 Office。任何关注技术行业颠覆故事的人都清楚，新技术进步带来的不对称商业模式攻击是竞争对手可以采取的最有效战略之一。

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. Hyper-ventilation by journalists and analysts about the pace of Google App’s innovation generally ignored the fact that the applications remained relatively simple. Prior to joining Microsoft, I had built a highly functional multimedia document editor which included word-processing, spreadsheets, image, graphics, email and real-time conferencing with a couple other developers. I knew the pace of innovation that was possible when functionality was still relatively low (“highly functional” but still small N compared to the Office apps) and nothing I saw as Google Apps evolved challenged that.
我们很清楚的一点是，云/浏览器开发战略并没有像我在这里讨论的那样，在基本复杂性的限制方面带来突破。事实上，在浏览器中运行大量代码或大型数据模型以及管理应用程序前端和后端之间的高相对延迟所面临的性能挑战，通常会增加在基于网络的环境中构建复杂应用程序的难度。记者和分析师们对谷歌应用创新速度的过度吹捧通常忽略了一个事实，那就是谷歌应用仍然相对简单。在加入微软之前，我曾与其他几位开发人员一起创建了一个功能强大的多媒体文档编辑器，其中包括文字处理、电子表格、图像、图形、电子邮件和实时会议。我知道，在功能还相对较少（"功能很强"，但与 Office 应用程序相比仍然很小）的时候，创新的速度是可能的，而我所看到的 Google Apps 的发展并没有挑战这一点。

In fact, several areas that demonstrate real cross-cutting complexity challenges is where Google’s slower pace is especially relevant. Google Apps have been announcing some variant of offline editing for almost 8 years now and it is still semi-functional. The other “real soon now” promise is “better compatibility with Office”. This has the flavor of the laundry detergent claims of “now with blue crystals”! The claim of “better” is hard to argue with but history would seem to indicate they are not getting any closer to actually being compatible, especially as Office continues to evolve. The final area is in native applications. Google has built relatively simple native applications for mobile but has not shown any interest in really fully investing there. Native applications would add a high N degree of complexity to all future work because the base technology and architecture are so different from the web-based versions, at least if they are actually interested in leveraging native device capabilities. It was clear that they were going to either continue to only timidly invest in native code and real compatibility, or they would invest and immediately start facing these complexity challenges that would slow how fast they could evolve and focus on actual differentiation. Either approach would be good for us competitively and that view of their available options was strongly influenced by this model of essential complexity.
事实上，有几个领域确实面临着跨领域的复杂性挑战，这正是谷歌放慢脚步的原因所在。近 8 年来，Google Apps 一直在宣布某种离线编辑功能，但至今仍处于半功能状态。另一个 "很快就能实现 "的承诺是 "更好地兼容 Office"。这就像洗衣粉宣称的 "现在有蓝水晶 "一样！更好 "的说法很难让人反驳，但历史似乎表明它们并没有更接近真正的兼容，尤其是随着 Office 的不断发展。最后一个领域是本地应用程序。谷歌已经为移动设备开发了相对简单的本地应用程序，但并没有表现出真正全面投入的兴趣。由于基础技术和架构与基于网络的版本有很大不同，原生应用程序将给未来的所有工作增加高度的复杂性，至少如果他们真的有兴趣利用原生设备的功能的话。很明显，他们要么继续怯懦地投资于本地代码和真正的兼容性，要么投资后立即开始面临这些复杂性的挑战，从而放慢发展速度并专注于实际的差异化。无论采用哪种方法，对我们的竞争力都是有利的，而他们对现有选择的看法也深受这种基本复杂性模式的影响。

None of this meant we took the challenge less seriously. In fact, it was clear that they were using an asymmetric technical attack of leveraging their simplicity to deliver sharing and co-editing features. These features were clearly differentiated and would be immensely hard to deliver on top of the existing highly functional (large N) Office apps. As we started building the web apps, we needed to decide whether we were going to “walk away” from our own complexity like we had when we developed OneNote or embrace the existing complexity, with the costs and constraints that that would imply for future development.
但这并不意味着我们不重视这一挑战。事实上，很明显，他们正在使用一种不对称的技术攻击，利用其简洁性来提供共享和共同编辑功能。这些功能显然是与众不同的，很难在现有的高功能（大 N）Office 应用程序基础上实现。当我们开始构建网络应用程序时，我们需要决定是像开发 OneNote 时那样 "放弃 "自己的复杂性，还是接受现有的复杂性，并承担由此带来的成本和对未来开发的限制。

The final decision to build the “Word Web App” rather than “a new web-based word processor from Microsoft that is not fully compatible with Word” (and similarly for Excel, PowerPoint and OneNote) was strongly driven by the belief that the file formats continued to serve as a critical competitive moat with immensely strong network effects. In fact, an argument can be made that the Office file formats represent one of the most significant network-based moats in business history (with Win32 and the iOS APIs as two others). Even applications like OpenOffice that were specifically designed to be clones have struggled with compatibility for decades. By embracing that complexity, and the costs, we would deliver something that we knew was fundamentally hard to match, especially if there was any confusion or hesitancy about the commitment required to compete. (I’ll just note that our decision to build the Sway product (http://sway.com) was fundamentally a decision to “walk away” from complexity and explore innovating in a way that could take a fundamentally different architectural approach from the existing Office apps without any of the compatibility constraints).
之所以最终决定建立 "Word Web App"，而不是 "微软推出的与 Word 不完全兼容的新网络文字处理器"（Excel、PowerPoint 和 OneNote 也是如此），是因为我们坚信，文件格式仍然是具有强大网络效应的重要竞争护城河。事实上，可以说 Office 文件格式是商业史上最重要的基于网络的护城河之一（另外两个是 Win32 和 iOS API）。即使是 OpenOffice 这样专门设计用于克隆的应用程序，几十年来也一直在兼容性问题上挣扎。通过接受这种复杂性和成本，我们将提供我们知道从根本上难以匹敌的产品，尤其是在对竞争所需的承诺存在任何困惑或犹豫的情况下。(我只想说，我们之所以决定开发 Sway 产品（http://sway.com），从根本上说，就是决定 "放弃 "复杂性，探索一种创新的方式，采用与现有 Office 应用程序完全不同的架构方法，而不受任何兼容性限制）。

It is now ten years later. Office has full platform coverage with native applications on all devices and highly functional and compatible web applications. These all support sharing, co-authoring and offline use. Full real-time co-editing is being rolled out now and was as hard to implement in the native applications as we had expected. Real-time co-editing, to the extent it is used and valued, reinforces the file format moat since it is technically implausible to imagine two independent implementations with different underlying data models achieving that fine degree of real-time interoperability. The Office implementations highly leverage shared code implementations of the core engines across both native and web clients to achieve that interoperability.
十年后的今天。Office 实现了全平台覆盖，在所有设备上都有本地应用程序，还有功能强大、兼容性强的网络应用程序。这些应用程序都支持共享、共同编辑和离线使用。完全实时的共同编辑功能目前正在推出，但正如我们所预料的那样，很难在本地应用程序中实现。实时协同编辑的使用和价值加强了文件格式的护城河，因为从技术上讲，要想象两个具有不同基础数据模型的独立实施方案实现如此高程度的实时互操作性是不可能的。Office 实现高度利用了本地和网络客户端核心引擎的共享代码实现来实现这种互操作性。

Competitive strategy argues that when a competitor attempts to differentiate you need to focus on neutralizing that differentiation as quickly as possible. The path we took did not accomplish that. Google was able to establish a critical competitive beachhead by building on their differentiation. I think it is still too early to see how this will all play out. 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.
竞争战略认为，当竞争对手试图进行差异化竞争时，你需要集中精力尽快消除这种差异化。我们所走的道路并没有做到这一点。谷歌在差异化的基础上建立起了重要的竞争滩头阵地。我认为，现在看这一切将如何发展还为时尚早。很显然，如果我们对迎接复杂性的挑战有任何胆怯，Office 应用程序的功能定位就不会像现在这样（在所有设备上完全兼容本地和网络客户端，并支持离线和协同编辑）。这种复杂性（因为它体现了有价值的功能）就是护城河。

This is probably already way too long but I also wanted to just touch on the ongoing discussions we had with Bill Gates over my entire career at Microsoft that directly related to these perspectives on complexity.
这篇文章可能已经太长了，但我还想谈谈我在微软的整个职业生涯中与比尔-盖茨持续进行的讨论，这些讨论与复杂性的这些观点直接相关。

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. For a time he believed that Trident (the core engine for Internet Explorer) could become that component. 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).
比尔希望（现在仍然希望）在如何构建丰富的生产力应用程序方面取得突破。他预计，这种突破的形式将是构建一个功能强大的组件，作为所有应用程序的核心引擎。有一段时间，他认为 Trident（Internet Explorer 的核心引擎）可以成为这种组件。这种模式会让你投资构建一个功能越来越强大的组件，而这个组件在整个应用程序中的比重会越来越大（因此，每个应用程序的构建成本会在所有应用程序中分摊）。

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. The alternate strategy is to emphasize isolating complexity, creating simpler functional components, and extracting and refactoring sharable components on an ongoing basis. That approach is also strongly influenced by the end-to-end argument and a view that you want to structure the overall system in a way that lets applications most directly optimize for their specific scenario and design point. That sounds a little apple pie and in practice is a lot messier to achieve than it is to proclaim. Determining which components are worth isolating, getting teams to agree and unify on them rather than letting “a thousand flowers bloom” is hard ongoing work. It does not end up looking like a breakthrough — it looks like an engineering team that is just getting things done. That always seemed like a worthy goal to me.
我在这里描述的这种观点认为，功能交互的增加会导致基本复杂性的增加，由此得出的结论是，这样一个组件最终会因为它需要服务的主人的所有复杂性和制约因素的结合而痛苦不堪。最终，它将因自身的重量而崩溃。另一种策略是强调隔离复杂性，创建更简单的功能组件，并不断提取和重构可共享的组件。这种方法也深受端到端论点的影响，并受到一种观点的影响，即你希望以一种能让应用程序最直接地针对其特定场景和设计点进行优化的方式来构建整个系统。这听起来有点像苹果派，而且在实践中，实现起来要比宣称的复杂得多。确定哪些组件值得隔离，让团队就这些组件达成一致并统一意见，而不是任由 "百花齐放"，这是一项艰苦的持续性工作。它最终看起来并不像一个突破--它看起来就像一个工程团队在完成任务。在我看来，这始终是一个值得追求的目标。