<div data-type="footnotes"><p data-type="footnote" id="ch01fn1"><sup><a href="#ch01fn1-marker">1</a></sup>We don’t mean “execution lifetime,” we mean “maintenance lifetime”—how long will the code continue to be built, executed, and maintained? How long will this software provide value?</p><p data-type="footnote" id="ch01fn2"><sup><a href="#ch01fn2-marker">2</a></sup>This is perhaps a reasonable hand-wavy definition of technical debt: things that “should” be done, but aren’t yet—the delta between our code and what we wish it was.</p><p data-type="footnote" id="ch01fn3"><sup><a href="#ch01fn3-marker">3</a></sup>Also consider the issue of whether we know ahead of time that a project is going to be long lived.</p><p data-type="footnote" id="ch01fn4"><sup><a href="#ch01fn4-marker">4</a></sup>There is some question as to the original attribution of this quote; consensus seems to be that it was originally phrased by Brian Randell or Margaret Hamilton, but it might have been wholly made up by Dave Parnas. The common citation for it is “Software Engineering Techniques: Report of a conference sponsored by the NATO Science Committee,” Rome, Italy, 27–31 Oct. 1969, Brussels, Scientific Affairs Division, NATO.</p><p data-type="footnote" id="ch01fn5"><sup><a href="#ch01fn5-marker">5</a></sup>Frederick P. Brooks Jr. <em>The Mythical Man-Month: Essays on Software Engineering</em> (Boston: Addison-Wesley, 1995).</p><p data-type="footnote" id="ch01fn6"><sup><a href="#ch01fn6-marker">6</a></sup>Appcelerator, “<a href="https://oreil.ly/pnT2_">Nothing is Certain Except Death, Taxes and a Short Mobile App Lifespan</a>,” Axway Developer blog, December 6, 2012.</p><p data-type="footnote" id="ch01fn7"><sup><a href="#ch01fn7-marker">7</a></sup>Your own priorities and tastes will inform where exactly that transition happens. We’ve found that most projects seem to be willing to upgrade within five years. Somewhere between 5 and 10 years seems like a conservative estimate for this transition in general.</p><p data-type="footnote" id="ch01fn8"><sup><a href="#ch01fn8-marker">8</a></sup>To his credit, Hyrum tried really hard to humbly call this “The Law of Implicit Dependencies,” but “Hyrum’s Law” is the shorthand that most people at Google have settled on.</p><p data-type="footnote" id="ch01fn9"><sup><a href="#ch01fn9-marker">9</a></sup>See “<a href="http://xkcd.com/1172">Workflow</a>,” an <em>xkcd</em> comic.</p><p data-type="footnote" id="ch01fn10"><sup><a href="#ch01fn10-marker">10</a></sup>A type of Denial-of-Service (DoS) attack in which an untrusted user knows the structure of a hash table and the hash function and provides data in such a way as to degrade the algorithmic performance of operations on the table.</p><p data-type="footnote" id="ch01fn11"><sup><a href="#ch01fn11-marker">11</a></sup>Beyer, B. et al. <a class="orm:hideurl" href="http://shop.oreilly.com/product/0636920041528.do"><em>Site Reliability Engineering: How Google Runs Production Systems</em></a>. (Boston: O'Reilly Media, 2016).</p><p data-type="footnote" id="ch01fn12"><sup><a href="#ch01fn12-marker">12</a></sup>Whenever we use “scalable” in an informal context in this chapter, we mean “sublinear scaling with regard to human interactions.”</p><p data-type="footnote" id="ch01fn13"><sup><a href="#ch01fn13-marker">13</a></sup>This is a reference to the popular song "Single Ladies," which includes the refrain “If you liked it then you shoulda put a ring on it.”</p><p data-type="footnote" id="ch01fn14"><sup><a href="#ch01fn14-marker">14</a></sup>Specifically, interfaces from the C++ standard library needed to be referred to in namespace std, and an optimization change for <code>std::string</code> turned out to be a significant pessimization for our usage, thus requiring some additional workarounds.</p><p data-type="footnote" id="ch01fn15"><sup><a href="#ch01fn15-marker">15</a></sup>Beyer et al. <em>Site Reliability Engineering: How Google Runs Production Systems</em>, Chapter 5, "Eliminating Toil."</p><p data-type="footnote" id="ch01fn16"><sup><a href="#ch01fn16-marker">16</a></sup>In our experience, an average software engineer (SWE) produces a pretty constant number of lines of code per unit time. For a fixed SWE population, a codebase grows linearly—proportional to the count of SWE-months over time. If your tasks require effort that scales with lines of code, that’s concerning.</p><p data-type="footnote" id="ch01fn17"><sup><a href="#ch01fn17-marker">17</a></sup>This is not to say that decisions need to be made unanimously, or even with broad consensus; in the end, someone must be the decider. This is primarily a statement of how the decision-making process should flow for whoever is actually responsible for the decision.</p></div></section>
0 commit comments