<?xml version="1.0"?>
<?xml-stylesheet href="/transform" type="text/xsl"?>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:bibo="http://purl.org/ontology/bibo/" xmlns:bs="http://purl.org/ontology/bibo/status/" xmlns:ci="https://vocab.methodandstructure.com/content-inventory#" xmlns:dct="http://purl.org/dc/terms/" xmlns:foaf="http://xmlns.com/foaf/0.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:xhv="http://www.w3.org/1999/xhtml/vocab#" xmlns:xsd="http://www.w3.org/2001/XMLSchema#" lang="en" prefix="bibo: http://purl.org/ontology/bibo/ bs: http://purl.org/ontology/bibo/status/ ci: https://vocab.methodandstructure.com/content-inventory# dct: http://purl.org/dc/terms/ foaf: http://xmlns.com/foaf/0.1/ rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns# xhv: http://www.w3.org/1999/xhtml/vocab# xsd: http://www.w3.org/2001/XMLSchema#" vocab="http://www.w3.org/1999/xhtml/vocab#" xml:lang="en">
  <head>
    <title property="dct:title">The Principle of One Degree</title>
    <base href="https://doriantaylor.com/the-principle-of-one-degree"/>
    <link href="document-stats#ECuiO8kSsuvXW_YAvs-epL" rev="ci:document"/>
    <link href="elsewhere" rel="alternate bookmark" title="Elsewhere"/>
    <link href="this-site" rel="alternate index" title="This Site"/>
    <link href="http://purl.org/ontology/bibo/status/published" rel="bibo:status"/>
    <link href="" rel="ci:canonical" title="The Principle of One Degree"/>
    <link href="lexicon/#EgKBzmX3EeQ5uHb5NelbqL" rel="dct:audience" title="Project Manager"/>
    <link href="person/dorian-taylor#me" rel="dct:creator" title="Dorian Taylor"/>
    <link href="knowledge-graph" rel="dct:hasPart"/>
    <link href="//www.amazon.com/dp/0201835959" rel="dct:references"/>
    <link href="lexicon/#EAdohOSM0U6cjYu1rAG22K" rel="dct:subject" title="Software Development"/>
    <link href="person/dorian-taylor" rel="meta" title="Who I Am"/>
    <link about="./" href="3f36c30c-6096-454a-8a22-c062100ae41f" rel="alternate" type="application/atom+xml"/>
    <link about="./" href="f07f5044-01bc-472d-9079-9b07771b731c" rel="alternate" type="application/atom+xml"/>
    <link about="./" href="this-site" rel="alternate"/>
    <link about="./" href="elsewhere" rel="alternate"/>
    <link about="./" href="e341ca62-0387-4cea-b69a-cdabc7656871" rel="alternate" type="application/atom+xml"/>
    <link about="verso/" href="3f36c30c-6096-454a-8a22-c062100ae41f" rel="alternate" type="application/atom+xml"/>
    <link about="verso/" href="this-site" rel="alternate"/>
    <link about="verso/" href="elsewhere" rel="alternate"/>
    <meta content="the-principle-of-one-degree" datatype="xsd:token" property="ci:canonical-slug"/>
    <meta content="Though wildly unpredictable in character, the projects with which we concern ourselves in the 21st century reduce to actions that incur little if any capital or indeed any variable cost. Instead of betting on the successful engineering of an outcome to occur within a fixed envelope of cost and time, it may be beneficial to put immediately to work the results obtainable within a single conceptual degree." name="description" property="dct:abstract"/>
    <meta content="2010-03-11T07:22:35+00:00" datatype="xsd:dateTime" property="dct:created"/>
    <meta content="the-principle-of-one-degree" property="dct:identifier"/>
    <meta content="2010-03-11T08:43:10+00:00" datatype="xsd:dateTime" property="dct:issued"/>
    <meta content="2010-03-11T08:42:12+00:00" datatype="xsd:dateTime" property="dct:modified"/>
    <meta content="2010-03-11T08:44:04+00:00" datatype="xsd:dateTime" property="dct:modified"/>
    <meta content="2010-03-11T08:44:37+00:00" datatype="xsd:dateTime" property="dct:modified"/>
    <meta content="2010-03-11T08:50:25+00:00" datatype="xsd:dateTime" property="dct:modified"/>
    <meta content="2010-03-11T08:52:58+00:00" datatype="xsd:dateTime" property="dct:modified"/>
    <meta content="2010-03-11T09:42:33+00:00" datatype="xsd:dateTime" property="dct:modified"/>
    <meta content="2010-03-11T23:53:11+00:00" datatype="xsd:dateTime" property="dct:modified"/>
    <meta content="2010-03-11T23:58:06+00:00" datatype="xsd:dateTime" property="dct:modified"/>
    <meta content="2010-03-12T00:02:47+00:00" datatype="xsd:dateTime" property="dct:modified"/>
    <meta content="2010-03-12T00:04:28+00:00" datatype="xsd:dateTime" property="dct:modified"/>
    <meta content="2010-03-12T00:04:51+00:00" datatype="xsd:dateTime" property="dct:modified"/>
    <meta content="2010-03-12T00:05:08+00:00" datatype="xsd:dateTime" property="dct:modified"/>
    <meta content="2010-03-12T00:23:46+00:00" datatype="xsd:dateTime" property="dct:modified"/>
    <meta content="2010-03-12T00:26:01+00:00" datatype="xsd:dateTime" property="dct:modified"/>
    <meta content="2010-03-12T00:36:19+00:00" datatype="xsd:dateTime" property="dct:modified"/>
    <meta content="2010-03-12T00:38:40+00:00" datatype="xsd:dateTime" property="dct:modified"/>
    <meta content="2010-03-12T01:09:31+00:00" datatype="xsd:dateTime" property="dct:modified"/>
    <meta content="2010-03-12T01:12:11+00:00" datatype="xsd:dateTime" property="dct:modified"/>
    <meta content="2010-03-12T01:12:49+00:00" datatype="xsd:dateTime" property="dct:modified"/>
    <meta content="2010-03-12T01:19:23+00:00" datatype="xsd:dateTime" property="dct:modified"/>
    <meta content="2010-03-12T01:21:06+00:00" datatype="xsd:dateTime" property="dct:modified"/>
    <meta content="2010-03-12T01:55:33+00:00" datatype="xsd:dateTime" property="dct:modified"/>
    <meta content="2010-03-12T02:22:46+00:00" datatype="xsd:dateTime" property="dct:modified"/>
    <meta content="2010-03-29T20:41:09+00:00" datatype="xsd:dateTime" property="dct:modified"/>
    <meta content="2010-08-27T03:40:18+00:00" datatype="xsd:dateTime" property="dct:modified"/>
    <meta content="2022-05-31T04:18:52+00:00" datatype="xsd:dateTime" property="dct:modified"/>
    <meta content="2022-05-31T15:10:50+00:00" datatype="xsd:dateTime" property="dct:modified"/>
    <meta about="person/dorian-taylor#me" content="Dorian Taylor" name="author" property="foaf:name"/>
    <meta content="summary" name="twitter:card"/>
    <meta content="@doriantaylor" name="twitter:site"/>
    <meta content="The Principle of One Degree" name="twitter:title"/>
    <meta content="Though wildly unpredictable in character, the projects with which we concern ourselves in the 21st century reduce to actions that incur little if any capital or indeed any variable cost. Instead of betting on the successful engineering of an outcome to occur within a fixed envelope of cost and time, it may be beneficial to put immediately to work the results obtainable within a single conceptual degree." name="twitter:description"/>
    <object>
      <nav>
        <ul>
          <li>
            <a href="cell-calendar" rev="dct:references" typeof="bibo:Article">
              <span property="dct:title">Cell Calendar</span>
            </a>
          </li>
          <li>
            <a href="deliverables-simple-and-complex" rev="dct:references" typeof="bibo:Article">
              <span property="dct:title">Deliverables, Simple and Complex</span>
            </a>
          </li>
          <li>
            <a href="giant-conf-2014-dissolving-the-redesign" rev="dct:references" typeof="bibo:Article">
              <span property="dct:title">GIANT Conf 2014: Dissolving the Redesign</span>
            </a>
          </li>
          <li>
            <a href="pot-pourri" rev="dct:references" typeof="bibo:Article">
              <span property="dct:title">Pot-Pourri</span>
            </a>
          </li>
          <li>
            <a href="the-roi-of-a-solved-problem" rev="dct:references" typeof="bibo:Article">
              <span property="dct:title">The ROI of a Solved Problem</span>
            </a>
          </li>
          <li>
            <a href="the-topological-thinness-of-summer-daisies" rev="dct:references" typeof="bibo:Article">
              <span property="dct:title">The Topological Thinness of Summer Daisies</span>
            </a>
          </li>
          <li>
            <a href="wants-and-needs" rev="dct:references" typeof="bibo:Article">
              <span property="dct:title">Wants and Needs</span>
            </a>
          </li>
          <li>
            <a href="document-stats#ECuiO8kSsuvXW_YAvs-epL" rev="ci:document" typeof="qb:Observation">
              <span>urn:uuid:0ae88ef2-44ac-4baf-b5d6-fd802fb3e7a9</span>
            </a>
          </li>
        </ul>
      </nav>
    </object>
  </head>
  <body about="" id="EkFsiirMinyavS3yfcoFXL" typeof="bibo:Article">
    <section id="EZ2MzKAgW1F-MD6BUHWIMI">
      <figure style="margin: auto; text-align: center" id="El6jngGH7VXvmzqcT2QgEJ">
        <img src="knowledge-graph;scale=500,400" alt=""/>
      </figure>
      <p>Suppose we treat a body of information as a network of symbols. The symbols are connected to one another by associative relationships. In order to be <em>knowledge</em>, a subset of the network has to be completely contained inside an individual person's brain. The parts of this subset of which a person is consciously aware can be understood as <em>known knowns</em> and unconscious or innate abilities are <em>unknown knowns</em>.</p>
      <p>Of course since brains have finite dimensions, they also have finite capacity. When you hit upon one of these edges you get into uncharted intellectual territory. You can see the cognitive corner, but you can't see around it. Consider these to be <em>known unknowns</em>. You can discuss them with your friends, even plan their discovery. But note that it is only their <em>discovery</em> that you can plan, that is, the specific acts of sifting through the record, asking for help or experimenting directly. In order to be put to use, known unknowns must at least be converted into known knowns. The information has to physically move from outside to inside your skull. We typically call this activity <em>learning</em> and its outcome <em>understanding</em>.</p>
      <p>Beyond that, there is a sea of information about the world that you don't even know exists. It lies at least one logical step farther out from known unknowns. You can't predict or prognosticate about it or even talk about it at all in great detail. You can only sort of characterize its existence and get used to its effect. You can even be sitting next to somebody who knows a critical answer or it could be lying in a book somewhere or in the flotsam in your kitchen junk drawer, but you will never be aware of it unless you convert an adjacent known unknown into a known known. The objects in this realm, as you probably expect, are <a href="http://en.wikipedia.org/wiki/Unknown_unknown" title="Unknown unknown &#x2014; Wikipedia" rel="dct:references">unknown unknowns</a>.</p>
    </section>
    <section id="E1b7d_2T4yOZ_Y7sThBbvI">
      <h2><a href="http://en.wikipedia.org/wiki/Laplace%27s_demon" title="Laplace's demon &#x2014; Wikipedia" rel="dct:references">Laplace's Demon</a></h2>
      <p>I just took three paragraphs to slog through this banal exercise because I wish to discuss <em>projects</em>. A project can be understood as any undertaking that on the whole is not already reduced to practice. For instance, you may not have done whatever it is you're trying to do before. Or you may know how to do it in principle, but not this particular instance. And the complexity of the task doesn't matter, only how well-understood it is. Designing a new phone is a project, putting one together on an assembly line is not. Any project naturally encounters a great deal of both known and unknown unknowns, even if everything can be accounted for but the inherent uncertainty in the universe between kick-off and expected completion. What makes a project a project is that you can't just go out and <em>do</em> it, because if you could you'd have done it already.</p>
      <p>The projects that concern themselves chiefly with moving lumps of atoms around tend to obey a fairly mundane subset of physics. That is to say that the set of unknown unknowns is actually pretty well-known. Snags in supply chain, logistics, energy, money and people all behave within a relatively well-understood envelope. If you pad your estimates accordingly, you can often draw the whole endeavour up in a pretty <a href="http://en.wikipedia.org/wiki/Gantt_chart" title="Gantt chart &#x2014; Wikipedia" rel="dct:references">Gantt chart</a> and execute the plan within an <a href="http://en.wikipedia.org/wiki/Order_of_magnitude" title="Order of magnitude &#x2014; Wikipedia" rel="dct:references">order of magnitude</a> of projected costs and time. If the market changes, a war breaks out or a meteor strikes, you shrug your shoulders at the freak event and start again from square one.</p>
    </section>
    <section id="EeYTVN6OHwpkmK2DClVJuL">
      <h2>Principle of One Degree</h2>
      <p>But we don't really move atoms around so much anymore, do we? Well, we probably do more than ever, but they are usually subject to the moving around of <a href="http://en.wikipedia.org/wiki/Binary_digit" title="Binary digit &#x2014; Wikipedia" rel="dct:references">bits</a>. We also have a serious addiction to novelty in our projects, or as we call it, <em>innovation</em>. The envelope of unknown unknowns is thus <em>wild</em>. The kinds of cataclysms that can torpedo a project, especially one that is subject to the sclerosis of the feature-budget-schedule calculus of industrial-age project management, are the <em>rule</em>, not the exception.</p>
      <p>The <a href="http://en.wikipedia.org/wiki/Agile_software_development" title="Agile software development &#x2014; Wikipedia" rel="dct:references">Agile software development processes</a> attempt to mitigate this condition by, <a href="http://agilemanifesto.org/principles.html" title="Principles behind the Agile Manifesto" rel="dct:references">as they declare in their manifesto</a>, <q>early and continuous <span class="parenthesis" title="Software is discrete by nature. You cannot deliver it continuously, only continually.">[sic]</span> delivery of valuable software</q>. They still, however, make the critical mistake of promising concrete results upstream for which they simply cannot account. Developers willingly put themselves under employer and/or investor pressure to deliver a result that lies deep beyond the boundary of known unknowns. Something has to give, and that something is usually the developers &#x2014; to the blunting, if not failure, of the entire project.</p>
      <p>My solution here is simply to <em>not do that deal</em>. Abandon attempts to venture deep into the Gantt chart and instead go wide along the perimeter of known unknowns, using a <strong>principle of one degree</strong>. Once you have assembled a surfeit of valuable precursor knowledge and method, your original goal itself nears to just one degree of associative distance away and can be acquired in the same fashion. And that happens whenever it happens.</p>
      <p>With this statement I can almost hear the incredulous howls of <acronym title="Masters of Business Administration">MBA</acronym>s, reciting <a href="http://en.wikipedia.org/wiki/Parkinson%27s_Law" title="Parkinson's law &#x2014; Wikipedia" rel="dct:references">Parkinson's law</a> and insisting that if you don't give a project a deadline, it'll never get done. I'm sorry to say it, ladies and gents, but you're butting up against a basic property of the physics of information. We're talking about specific, <a href="http://en.wikipedia.org/wiki/Fungibility" title="Fungibility &#x2014; Wikipedia" rel="dct:references">infungible</a> data, <a href="from-the-edges-of-the-universe-to-neighbouring-nanometres" title="From the Edges of the Universe to Neighbouring Nanometres" rel="dct:references">physically leaping across the cosmos</a> and into the brains of individual human beings. Furthermore, your project will hobble along until this process has occurred sufficiently in the mind of <em class="parenthesis" title="because it does not help for two people to each possess half an idea">exactly one person</em> such that he or she <a href="pk" title="Notes from Pecha Kucha" rel="dct:references">understands the problem</a> and possesses the intrinsic will and the wherewithal to make success happen. As a project manager you cannot escape this reality; you can only decide whether or not you want to <a href="http://www.amazon.com/gp/product/0201835959?ie=UTF8&amp;tag=doriantaylor-20&amp;linkCode=as2&amp;camp=1789&amp;creative=390957&amp;creativeASIN=0201835959" title="The Mythical Man-Month">treat it systematically</a>.</p>
    </section>
    <section id="Ek6wEfTkqjVyKKBGpljiCK">
      <h2>You Just Called My Babies Ugly</h2>
      <p>Maybe, but everybody was thinking it. While I have your attention, just how essential are the feature list, budget and schedule anyway?</p>
      <p>A feature request, recently quaintly relabeled <a href="http://en.wikipedia.org/wiki/User_story" title="User story &#x2014; Wikipedia" rel="dct:references"><em>user story</em></a>, is little more than a heavily-digested line item on a work order. It is nearly always presented completely divorced from its reason for being and is widely open to interpretation, despite the fact that it prescribes both a unit of work and an aspect of the form of the final product. These are not trivial artifacts, <a href="moar-feecharz" title="MOAR FEECHARZ." rel="dct:references">nor are they of first order</a>. Figuring out what features a product ought to exhibit is a derivative of figuring out its desired <em>behaviour</em>, which itself is a derivative of figuring out who is going to <em>buy</em> and separately who is going to <em>use</em> the product &#x2014; a deeply intensive endeavour that carries its own unpredictable, though not necessarily astronomical cost.</p>
      <p>The schedule and the budget are two heads of the same hydra. Apocryphally they once served to <em>inform</em> progress and the procurement of resources, not <em>dictate</em> them. Currently they behave like more tools in the <a href="http://en.wikipedia.org/wiki/Procrustes" title="Procrustes &#x2014; Wikipedia" rel="dct:references">Procrustean kit bag</a>.</p>
      <p>A budget can be cast as a shopping list harmonized into currency. Where we fail with budgets is to use them to prescribe the costs of acquisitions that are not well-understood. On a project you are breaking new ground by definition. It is not a trip to Costco.</p>
      <p>A schedule can just as easily be read as a means of planning the next moves of a group of like-minded people as it can be used as a weapon to extort backflips and contortions out of the very same. People tend to have more than one responsibility at a time, however, and it is only the na&#xEF;ve or imperious schedule that does not account for that.</p>
    </section>
    <section id="EVaR9PO4patKsfssFTzGYJ">
      <h2>Progress is Lumpy</h2>
      <p>A building, perhaps the archetypal project of all time, has the luxury of telling the story of its own progress. You can visit a construction site every successive week and monitor the digging of the pit, the pouring of the foundation and the incremental addition of floors and glazing until the structure reaches the top. Its dependency on gravity gives it a single, easy direction to follow: up.</p>
      <p>Projects not subject to this constraint have more freedom to move around but require some creativity to indicate the same thing. For instance, it would be lunacy to shoot a film in the order the scenes are played. A simple checklist of scenes <em>in the can</em>, however, would more than suffice to tell the story of progress through the most expensive part of its process. Of course, the ground of a construction site is only broken and a film project only goes to shoot when either have spent months to years in careful preparation.</p>
      <p>With the advent of software and networked information systems, we can go from zero to sales in hours or still be stuck effectively at zero after decades. The determinant for progress is not the availability of <a href="http://en.wikipedia.org/wiki/Factors_of_production" title="Factors of production &#x2014; Wikipedia" rel="dct:references">land, labour or capital</a>, but the <a href="lexicon/conceptual-integrity" title="Conceptual Integrity" rel="dct:references">conceptual integrity</a> within and between the people carrying out the endeavour. While the product development team may be closely-knit, each individual is on his or her own when it comes to understanding what to contribute and how to implement it. It is not sufficient for teammates to each possess a fraction of an idea.</p>
      <p>The ability to market a product immediately upon completion is indeed valuable, though it confuses the nature of the process. If we have full comprehension of our pending tasks and mow through them, we almost <em>machismically</em> <a href="why-build-software-when-you-can-define-it" title="Why Build Software When You Can Define It?" rel="dct:references">imagine ourselves as great builders</a>. But in the interim <a href="http://www.youtube.com/watch?v=lytxafTXg6c" title="YouTube - Richard Feynman explains the feeling of confusion" rel="dct:references">when we don't understand</a>, are we not more like a hapless artist or writer suffering a creative block? It seems as if we acquire progress on these ventures less like bricklaying and <a href="an-archimedean-bath" title="An Archimedean Bath" rel="dct:references">more like a great discovery</a>.</p>
    </section>
    <section id="ERS9YNdbdRkjAjKR77UnfL">
      <h2>The Result is Still Finite</h2>
      <p>We treat these projects as engineering endeavours crafted to fit into a <a href="byproducts-of-ambient-wealth" title="Byproducts of Ambient Wealth" rel="dct:references">hard shell of economic scarcity</a>. The reality is that there is enough gold in the machines upon which these systems run that were <em>thrown in the garbage</em> to <a href="http://www.scientificamerican.com/blog/post.cfm?id=winter-olympic-medals-made-from-rec-2010-02-12" title="Observations: Winter Olympic medals made from recycled e-waste" rel="dct:references">mint the most recent set of Olympic medals</a>.</p>
      <p>In an overwhelming number of post-industrial projects, the only kind of cost is that of an individual understanding a problem and writing down the answer. This process cannot be compressed any more than it can in the arts, sciences or indeed our own reproduction. Once a problem is solved, however, it can often be put to work almost immediately.</p>
      <p>It is important to remember that any attainable goal decomposes into a finite set of actions. Given sufficient complexity, however, the form, content and sequence of these actions can scarcely be determined at the outset. Nevertheless there remains the issue of securing the wherewithal to complete them, and it makes a great deal of sense to mitigate the risk at any given time to one degree of complexity. It might indeed make additional sense to finance the ultimate objective not principally with a generous yet fixed parcel of equity capital, but with revenue from the marketing of numerous <a href="http://www.ribbonfarm.com/2010/03/01/the-expedient-desirable-product/" title="Expedient Desirable Product" rel="dct:references">expedient, desirable products</a>.</p>
    </section>
  </body>
</html>
