The Code Economy is a book about the economic history of code, conceived broadly. To Phillip Auerswald, code is an generic term for any process, series of instructions, or algorithm - as well as any set of regulations, rules, or other heuristics by which behavior (of machines or people) should be governed. The question this book poses is, what does the history of code have to teach us about its past economic behavior, and what can it illuminate about the future of code and the broader economy?

The central insight, that the code which makes up software is part of a long history of well-defined processes and regulations in other endeavors, is very clever. I have been thinking along similar lines for a long time, and it’s very gratifying to read a book which seems to capture this insight so nicely. To rephrase the book’s informal definition a bit, the word “code” is a broad umbrella which covers any effort to take a real-world phenomenon and turn it into knowledge or behavior which can be shared in a reproducible format - hence everything from a recipe book to the US Constitution can be thought of as code.

Software engineers have a slightly different word for this kind of activity: abstraction. In the context of software engineering, abstraction has a very specific meaning related to the way a software program is written, and the way the engineer thinks about that process. One of the most important principles of software engineering is that it’s best to write software at a “higher level of abstraction” when possible - meaning that engineers seek to identify groups of instructions that occur repeatedly, and to work with those instructions as a group, rather than individually. Good engineering, in the terms of this principle, means grouping instructions together in the proper way, and doing so consistently.

Seen in the light of this book’s central insight, it seems that software engineers are just following an economic principle that has proven itself again and again. Which is to say, abstraction can be very lucrative. The global McDonald’s empire was built on an abstraction: the Speedee Service System, which was a rulebook governing how the original McDonald’s restaurant operated. The McDonald brothers grouped a set of restaurant management practices which together guaranteed consistency of product and speed of service and gave it a name. Identifying those practices, and putting them in writing with sufficient clarity, allowed someone else, Ray Kroc, to reproduce the practices and create a series of very successful franchises. This abstraction, coupled to any number of other factors, is today worth north of $100 billion. (Setting aside, for the moment, the numerous externalities it’s created over the years.) As a software engineer keenly concerned with the question of good abstraction, I think this insight is extremely illuminating and provides a lot of very helpful context for the things I think about every day.

The primary concern of this book is the behavior of code as an economic object. The argument is that code, when deployed in an economic setting, has tremendous impacts that economists shouldn’t ignore. That is true, and to a degree it’s something that is well-understood in corporate management, even if it’s not well-modeled in academic settings. For example, Intel explicitly models the gains to be made from new technologies, and the trajectory by which these gains will be realized - and those models in turn impact its financial forecasts. But at a higher level, academic economists lack the ability to model the impacts of code, and the degree to which it can produce value. It doesn’t seem to me that the book provides such a model - it merely makes the argument that the model should exist.

There is some attempt to provide the outline of a model, in particular owing to the discussion of platforms. Auerswald defines a platform as a piece of code that’s been standardized, and therefore may be readily operated and used by others - importantly, operated with relatively little skill. The example of Gaspard de Prony looms large in this discussion. Tasked with a vast land survey project in the aftermath of the French revolution, de Prony recognized that the project would require a tremendous amount of mathematical calculations. His major contribution was to create a system of management which made it possible for a large group of unskilled operators to follow a set of instructions to compute logarithms and trigonometric functions, without requiring a great deal of mathematical training. In a sense, his system of managing numerical methods was a kind of platform for producing computations. Fast forward a couple hundred years, and we can marvel at the fact that billions of people, the vast majority of whom have never heard of a transfer protocol and could not possibly prepare an electronic communication packet by hand, rely on HTTP on a daily basis.

Intuitively, it’s very useful to think of standardization as an important step in the lifecycle of a piece of code. But the discussion in this book lacks a certain degree of rigor. It doesn’t really consider the question of what constitutes a standard, how standards are maintained or how they fall into disuse, and so forth. Worse, the definition of a platform is slippery and imprecise. Auerswald calls the Internet a platform, and I think that’s clearly correct - there are a variety of well-defined standards and practices which make the Internet operate as it does.

However, the book also claims that the institution of the city is a platform, and I think that’s quite a stretch, in the context of any discussion of code. It presents a compelling case that the idea of creating a permanent, densely populated settlement represents a major advance in economic productivity, and I don’t doubt that. But it’s difficult to see how that history has anything to do with code, in the sense of a set of instructions that reliably reproduce a certain product over and over again. Although cities do share certain macrocosmic behaviors, it’s not at all clear that these common properties have very much to do with intentional planning - which, after all, varies greatly from one city to the next. It’s probably more correct to say that cities share these characteristics as an intrinsic property of being permanent, densely populated settlements. That is certainly very interesting, but it doesn’t have much to do with code.

Unfortunately, that’s not the only place where the book loses focus. The exposition on the discovery of DNA is a little muddled and pointless. Certainly it’s true that biological code and digital code share some very interesting properties, but it’s far from clear that any of those similarities have anything to do with the economy. Discussions on Burning Man and blockchain technology fit even less neatly into the overall argument. These chapters seem to be little more than buzzword magnets - they remind me of the trendy thought-leader books that emerged ten years ago, which all seemed to mention blogging, the open source movement, and 3D printers as a matter of rote necessity.

Writ large, I think the weakness of this book is that it presents an argument about code, but it’s written by an economist. There’s nothing wrong with that, but the book has a number of blind spots as a result. Except for a few amusing anecdotes about Julia Child and her mayonnaise experiments, there’s very little discussion on the actual process of creating and maintaining code. There’s even less thought about the mechanics of standards and platforms. Correspondingly, there’s not much insight about the similarities in the operation of code from one medium or another: how is the process of creating a software program similar to the process of crafting a recipe, and what does that say about the economic impacts of the one or the other? It’s a fascinating question, but the book has little to say about it.

Perhaps worst of all, in my view, is the simple fact that the book treats code as an economic object first and foremost. That is a real shame, because code - of any form, be it a software program, a system of laws, or a recipe book - is also an artistic object, something that is the result of significant expressive effort. I can’t fault the author for examining the economic impacts of code, which are obviously very significant. But it makes me a bit sad to see a complex, fascinating pursuit - coding - reduced to a question of dollars and cents.

On the whole, I’m very glad to have found and read this book. I think it’s the beginning of what I hope will be a much larger conversation about the similarities between software and other endeavors - economic and artistic - but alas, it’s just a beginning.