edit-article

Article Description: [SUMMARY] complexity-and-strategy - by Terry Crowley @medium.com - formerly @msft dev team, working on office products, frontpage(html editor), onenote, ... - how development of new features becomes more complex over time

Chapter ID/Name:

Status: Write Writing Written

Add Photo:

Owner ID:

Content: use HTML Edit Content <h1 style="text-align: center;">Complexity and Strategy<span style="font-size: 10px;">&nbsp;</span></h1> <h2>[WHAT]</h2> <ol> <li>] [SUMMARY] complexity-and-strategy - by Terry Crowley @medium.com - formerly @msft dev team, &nbsp;working on office products, frontpage(html editor), onenote, ... - how development of new features becomes more complex over time</li> </ol> <h2>[WHY]</h2> <ol> <li>]&nbsp;</li> </ol> <h2>[WHERE]</h2> <ol> <li><strong>] READ THE FULL ARTICLE</strong></li> <ol> <li>] <a href="https://medium.com/@terrycrowley/complexity-and-strategy-325cd7f59a92#.g8ifjkelz" target="_blank">https://medium.com/@terrycrowley/complexity-and-strategy-325cd7f59a92#.g8ifjkelz</a></li> </ol></ol> <h2>[WHEN]</h2> <ol> <li>] 2017-03-09</li> </ol> <h2>[EXAMPLE]</h2> <p>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 &ldquo;walk away&rdquo; from Word&rsquo;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&rsquo;s existing functionality.&nbsp;</p> <p>They would settle for a much smaller initial &ldquo;N&rdquo; 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.</p> <p>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?&mdash;?efforts using a new technology inherently start small so the benefits get conflated.&nbsp;</p> <p>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.&nbsp;</p> <p>Project after project has demonstrated there is nothing about language or underlying technical infrastructure that changes that fundamental curve.&nbsp;</p> <p>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?&mdash;?which leads to the general advice &ldquo;you ship it, you own it&rdquo;. This means that you eventually pay for all that code that lifted your initial productivity. So &ldquo;free code&rdquo; tends to be &ldquo;free as in puppy&rdquo; rather than &ldquo;free as in beer&rdquo;.</p> <h2>[HOW-TO]</h2> <ol> <li>]</li> </ol> <h2>[REFERENCE]</h2> <ol> <li>] SRC = tw by @ (LIST-startup-founders-A), check #foundersTalk 03-12</li> </ol> <h1 style="text-align: center;">&nbsp;</h1>