CHAPTER 22

Code

In any world, the current situation is not inevitable; “It might have been otherwise,” in the words of the American poet Jane Kenyon. Nowhere is this more true than in the world of computer code, which embeds past history, deeply buried assumptions and decisions, and future possibilities (or lack thereof). The ways in which the world is captured in code, and in which code is embedded in the world, are important to recognize if not fully comprehend.

“Code” is a wonderful word, one with many interweaving meanings. As Harvard law professor Lawrence Lessig brilliantly pointed out in his analysis of the Internet, the first meaning of the word relates to law and jurisprudence. Codes can also be systems of rules outside the law: a code of ethics. Most every child at some point gets fascinated with backward writing, letters to numbers (A=1, B=2, etc.), and other ways of transmitting secret messages: code as symbol, as in The Da Vinci Code. The genetic code is something else again. According to the Oxford English Dictionary, however, the relevant definition for our purposes is straightforward: “Any system of symbols and rules for expressing information or instructions in a form usable by a computer or other machine for processing or transmitting information.” Note how rules, representation, and a system are common to all meanings of the term.

It would be impossible to discuss all the changes wrought by our digital world without talking about code itself. Doing so, however, is extremely difficult, a bit like talking about the wind: We can readily see what it does (move leaves) but not what it is. A brief digression is necessary here. Code that makes things happen (moves characters in a game, performs operations in a spreadsheet, or turns on the car radio) is typically experienced as compiled code: One cannot see the potentially millions of operations behind the scenes while using FarmVille or Excel or a Volkswagen. (Decompiling the code is possible, and often done for the purpose of copying the program in violation of copyright, so decompilers often operate in a legal gray area.) If one so desires, Linux and other examples of open-source software allow the owner/user of the software to see behind the curtain and to change the code before it runs in compiled form. Generally speaking, a small minority of people tweak code before runtime, but even they can't reprogram their car's antilock brakes or make the microwave oven sing “Happy Birthday.” Most code is hidden, expert user or no expert user.

Intangibility

This quality of intangibility is a central fact of our age: For every 100 teenagers in 1961 who could understand and alter how a car ran by looking under the hood, only a handful of high schoolers today can modify a current video game or cell phone. Every car has a hood, an engine, spark plugs, wheels, a transmission, and the like. Physical laws govern the behavior of each component as well as the components' interaction. Physical senses allow an individual to see, hear, touch, and smell a properly—or improperly—running automobile.¹ Software, while exhibiting effects everywhere, remains hidden from the senses.

An exception helps prove the rule: From the early days of the World Wide Web, browsers included a control to reveal the page code, to show in a parallel window how the Web site was built.² The language that defined those pages was called Hypertext Markup Language, or HTML; it was lightweight and easy to learn. As the technical publisher Tim O'Reilly noted at the time, a generation of people learned to build Web sites by looking at how other people had built Web sites. HTML is a static language that describes appearance: It defines where page elements are placed, what colors appear, how big a font is, and the like. Nothing happens, unless you count crude animations. Meanings of and relationships between page elements are not specified.

For maps to slide with a mouse click, or videos to play, or payments to process, or Facebook to know friends from nonfriends, newer, more complex languages (and infrastructure such as databases, encryption, etc.) are required. With these, simple imitation will not suffice: You must be a programmer of at least modest experience to understand the workings of a current-day Web page, although tools exist for nontechnical people to build powerful sites with drag-and-drop editing. These more powerful Web pages, considered as code, have considerable implications, as we will see presently.

For the rest of us nonprogrammers, sensory appropriation does little or nothing to allow us to understand or manipulate code; no amount of baling wire or duct tape can fix a problem. For example, quantification has often been applied to programmer productivity metrics, as though mining coal or selling magazine subscriptions were similar to making computers work. “Lines of code written” proves to be a particularly bad way of judging programmer quality, as it turns out, but there are no easy yardsticks. Fred Brooks, a legend in the field of software engineering, writes of the “delight” the coder has in his materials:

Thus, as tempting as it is to equate code with the hardest of logic, with the unsurpassable lack of gray area implied by ones and zeros, there are ways in which code can best be understood as poetry, subject to the same loose laws of assessment, the same qualities of individual idiosyncratic genius, the same problems of meaning.

Before we leave Brooks, he makes one other salient point. Whereas progress can be assessed visually with physical media, computer code is not done when the program is complete but rather when it is tested and debugged. Inexperienced project managers regularly make this mistake, thinking of building construction when it is a dangerously misleading metaphor. Because code is invisible and people's sensory inputs do little to help them understand the extremely large numbers of potential interactions between subunits of a large system, testing and debugging are difficult tasks that require a particular discipline, sophisticated tools, and as much time as it takes to do the job—a quantity notably difficult to predict.

Fungibility

Testing and debugging also require the code to be done. For this to be accomplished, those building the system need to know what they are trying to build, then freeze the requirements. “Freezing the requirements” means saying no to people who change their mind or have new information. It also means stepping back from the essential malleability of code as well as the trait that allows it to do anything, its fungibility. These loops—of requirements, of design, of “just one more feature”—contribute to programs' being late, even before the project team faces the final task, which is finding errors, incompatibilities, and just plain mysteries that only appear at runtime.

Another fact of modern life separates us from the teenage mechanics of 50 years ago. Whereas an automobile engine, or a refrigerator compressor, could not play music, or balance the checkbook, or identify one's location, or conjure up Grandma's face and voice from either the past or the present, today's most basic digital devices can do any of these and all of these. That is, code is not only abstract and disembodied, it is ubiquitous and increasingly fungible: A GPS location becomes a social media posting becomes a mash-up becomes a song becomes a video becomes a game move.

Code Embeds Value Judgments

Broadly speaking, computer code does one of two things: It instructs some piece of hardware to do something, or it records a value (the product of having done something) for future recall and potentially manipulation. In a loose analogy, the former type of code functions as verbs; the latter is essentially nouns. During the early stages of any software project, decisions are made that determine the rules of the road for how those nouns and verbs will work together. As Kevin Kelly, an astute commentator on matters technological, has pointed out, those default assumptions are rarely discussed at their moment of inception and yet persist, in some cases for decades, imposing their will on generations of both users and tenders of the system.⁴ The legal scholar Lawrence Lessig is more concise: “Code codifies values, and yet, oddly, most people speak of code as if it were just a question of engineering.”⁵ Once again, the meanings of the term overlap.

Can (a) a user, (b) a systems administrator, or (c) no one change the color or the logo of the home screen? How are languages built on non-alphabetical elements, such as Arabic or Korean, rendered? In the credit crash of 2008, one credit-rating firm had a risk model in which housing prices never went down: False optimism was literally engineered into the system. The lack of sensory inputs and of “user-servicable” parts makes these embedded assumptions all the more powerful insofar as they cannot even be identified, much less adjusted. Furthermore, the large number of interacting variables makes isolating the relevant ones difficult or impossible: Systems debugging is a challenge for professionals who need to make the code run, and most people who want to understand what the code means find this barrier too steep to challenge with any regularity.

Metadata

As for the “noun” code, better known as data, we have more to say in the chapters on analytics (Chapter 29) and security (Chapter 7). From the perspective of pure code, data is important insofar as it is defined by more data. The bits on a compact disc can play a song, for example, but the CD standard developed by Sony and Philips has no provision for the name of the song, or the artist, to be included on the disc. These facts, the data about the data, are called metadata and are phenomenally interesting in the age of extremely broad digitization and connectedness.

A digital photograph, for example, embeds information about the camera, the time and date, the lens, the exposure settings, and other optional information, such as GPS coordinates. Metadata becomes complex and political when it is located in enterprise systems (when was this document created, when was the payment logged), and we will leave those aside for the moment.

In the era of Blogger, Facebook, and Flickr, the social web has broad-reaching implications for personal data. In the early days, before computing, there was data, enumerating how many, what kind, where. Data was kept in proprietary formats and physically located: If the university library was missing the Statistical Abstract for 1940, or some other grad student had sequestered it, you had little chance to determine corn production in Nebraska before World War II. Even such statistics were the exception: Most data remained unpublished, in lab notebooks and elsewhere, or uncollected.

Once data migrated from print into bits, it became potentially ubiquitous, and once formats became less proprietary, more people could gain access to more forms of data. The early history of the Web was built in part on a footing of public access to data: Online collections of maps, congressional votes, stock prices, phone numbers, product catalogs, and other data proliferated.

Data has always required metadata: That table of corn production had a title and probably a methodological footnote. Such metadata typically was contributed by an expert in either the technical field or in the practice of categorizing. Official taxonomies have continued the tradition of creators and curators having cognitive authority in the process of organizing. In addition, as Clay Shirky pointed out in his essay “Ontology Is Overrated,” the heritage of physicality led to the need for one answer being correct so that an asset could be found: A book about Russian and American agricultural policy during the 1930s had to live among books on Russian history, agricultural history, or U.S. history. It was arguably about any or all of those things, but someone (most likely at the Library of Congress) assigned it a catalog number that finalized the discussion: The book in question was officially and forever “about” this more than it was about that.⁶

In the past decade, the so-called read-write web (based on code that assigns values and relationships to the items on the page rather than merely describing their layout) has allowed anyone to become both a content creator and a metadata creator. Sometimes these activities coincide, as when someone tags her own YouTube video. More often, creations are submitted to a commons like YouTube or Flickr or Facebook, and the commoners (rather than a cognitive authority) determine what the contribution is “about” and if they “like” it. Rather than editors or peer reviewers judging an asset's quality before publication, in more and more settings, the default process is publication then collaborative filtering for definition, quality, and meaning.⁷

Imagine a particular propane torch for sale on Amazon.com. So-called social metadata has been nurtured and collected for years on the site. If I appreciate the way the torch works for its intended use of brazing copper pipe, I can submit a review with both a star rating and prose. Amazon quickly allowed for more social metadata as you the reader of my review can now rate my review, thus creating metadata about metadata.

Here is where the discussion gets complicated and extremely interesting. Suppose I say in my review that I use the Flamethrower 1000 for créme brûlée even though the device is not rated (by whatever safety or sanitation authority) for kitchen use. The comments about my torch review can quickly become a foodie discussion thread: the best créme brûlée recipe, the best restaurants at which to order it, regional variations in the naming or preparation of créme brûlée, and so forth. Amazon's moderators might truncate the discussion to the extent it's not “about” the Flamethrower 1000 under review, but the urge to digress has long been exhibited and will forever be demonstrated elsewhere.

Social Metadata

Enter Facebook. The platform is in essence a gigantic metadata generation and distribution system. (“I liked the concert.” “The person who liked the concert did not know what she was talking about.” “My friend was at the concert and said it was uneven.” And so on.) Strip Facebook of attribute data and there is little left: It's essentially a mass of descriptors (including “complicated”), created by amateurs and never claimed as authoritative, linked by a twenty-first-century kinship network. Facebook's adoption in 2010 of the Open Graph protocol institutionalizes this collection of conversations as one vast, logged, searchable metadata repository. If I “like” something, my social network can be alerted, and the Web site object of my affection will know as well.

In late 2009, the security expert Bruce Schneier laid out five categories of social networking data:

1. Service data. Service data is the data you need to give to a social networking site in order to use it. It might include your legal name, your age, and your credit card number.
2. Disclosed data. This is what you post on your own pages: blog entries, photographs, messages, comments, and so on.
3. Entrusted data. This is what you post on other people's pages. It's basically the same stuff as disclosed data, but the difference is that you don't have control over the data—someone else does.
4. Incidental data. Incidental data is data the other people post about you. Again, it's basically the same stuff as disclosed data, but the difference is that 1) you don't have control over it, and 2) you didn't create it in the first place.
5. Behavioral data. This is data that the site collects about your habits by recording what you do and who you do it with.⁸

What does Schneier's list look like in the aftermath of Facebook's decision in 2011 to use facial recognition to identify people in photographs as the default, without the individual's permission? A user's trail of “like” clicks makes this list, or her Netflix reviews and star ratings (themselves the subject of privacy concerns), seem like merely the tip of the iceberg. With anything so new and so massive in scale (50,000 sites adopted the “like” software tool kit in the first week), the unexpected consequences will take years to accumulate. What will it mean when every opinion we express online, from the passionate to the petty, gets logged in the Great Preference Repository in the Sky, never to be erased and forever being able to be correlated, associated, regressed, and otherwise algorithmically parsed?

Several questions follow: Who will have either direct or indirect access to the metadata conversation? What are the opt-in, opt-out, and monitoring/correction provisions? If I once mistakenly clicked a Budweiser “like” button but have since publicly declared myself a Molson man, can I see my preference library as if it's a credit score and remedy any errors or misrepresentations? What will be the rewards for brand monogamy versus the penalties for promiscuous “liking” of every product with a prize or a coupon attached?

While this technology appears to build barriers to competitive entry for Facebook, what happens if I establish a preference profile when I'm 14, then decide I no longer like zoos, American Idol, or Gatorade? Will people seek a fresh start at some point in an undefined network, with no prehistory? What is the mechanism for “unliking” something, and how far retrospectively will it apply?

Precisely because Facebook is networked, we've come a very long way from that Statistical Abstract on the library shelf. What happens to my social metadata once it traverses my network? How much or how little control do I have over what my network associates (“friends” in Facebook-speak) do with my behavioral and opinion data that come their way? As both the Burger King “Whopper Sacrifice” (defriend 10 people, get a hamburger coupon) and a more recent Ikea-spoofing scam have revealed, Facebook users will sell out their friends for rewards large and small, whether real or fraudulent.

Finally, to the extent that Facebook is both free to use and expensive to operate, the Open Graph model opens a fascinating array of revenue streams. If beggars can't be choosers, users of a free system have limited say in how that system survives. At the same time, the global reach of Facebook exposes it to a broad swath of regulators, not the least formidable of whom come out of the European Union's strict privacy rights milieu. As both the uses and inevitable abuses of the infinite metadata repository unfold, the reaction will be sure to be newsworthy.

Looking Ahead

Before we can look at GPS, or Facebook, or Amazon, it's helpful to understand that code's unique properties precondition the range of behavioral, economic, and technical possibilities. Above all, code is in its essence paradoxical. It is ephemeral yet permanent; as a colleague once said, “Digits never die.” Code is malleable yet frustratingly complex. Code is both universal, particularly when defined by powerful standards, and intimately personal: A given task can typically be performed any number of ways, and programmers develop stylistic “signatures.” Code can be fungible and intractable, as when a document looks different when opened on two seemingly similar PCs six inches apart.

Given these multiple layers of paradox, it is no surprise that so many facets of information, technology, and business strategy become puzzling, nonlinear, and counterintuitive as they are informed by the essential qualities of the twenty-first-century's lingua franca. Expect the situation to get more complicated, scarier, and farther reaching in the coming years as smartphones define more of everyday life.

Notes

1. For an extended meditation on code, including a better comparison to automobiles, Neal Stephenson's essay “In the Beginning Was the Command Line” is essential reading. http://artlung.com/smorgasborg/C_R_Y_P_T_O_N_O_M_I_C_O_N.shtml.

2. Tim O'Reilly, “The New Age of Infoware: Open Source and the Web” (Summer 1999), http://tim.oreilly.com/archives/mikro_age_of_infoware.pdf.

3. Frederick P. Brooks, Jr., The Mythical Man-Month: Essays on Software Engineering (Boston: Addison-Wesley, 1995), p. 7.

4. Kevin Kelly, “The Power of the Default,” The Technium blog, June 22, 2009, www.kk.org/thetechnium/archives/2009/06/triumph_of_the.php.

5. Lawrence Lessig, Code and Other Laws of Cyberspace (New York: Basic Books, 1999), p. 59.

6. Clay Shirky, “Ontology Is Overrated: Categories, Links, and Tabs,” Clay Shirky's Writings about the Internet (Spring 2005), www.shirky.com/writings/ontology_overrated.html.

7. Clay Shirky, Here Comes Everybody: The Power of Organizing Without Organizations (New York: Penguin, 2008), pp. 81 ff.

8. Bruce Schneier, “A Taxonomy of Social Networking Data,” Schneier on Security blog, November 19, 2009, www.schneier.com/blog/archives/2009/11/a_taxonomy_of_s.html.