The Case for Software Criticism

Software may be the defining cultural artifact of our age. It’s time to build a culture of critical analysis around it.

Here’s a quick typology of tech journalism today: news reporting (“Amazon Announces Layoffs Affecting 18,000 Employees”), gadget reviews, company and founder profiles, opinion essays (Zeynep Tufekci et al.), investigative work (“The Uber Files”), industry digests (TechCrunch), personal blogs, Substacks, and—if you’re feeling generous—Hacker News comments and GitHub “issues.” It’s an incomplete catalog, but you get the idea. Yet surveying this landscape reveals a curious lacuna: software criticism.

To be clear: Technology criticism is nothing new. Depending on who you ask, it goes way back to Lewis Mumford, Herbert Marcuse, Martin Heidegger, and Marshall McLuhan. More recently, I assume you’ve at least heard of popular books like The Age of Surveillance Capitalism and The Attention Merchants and may even be familiar with technology critics like Jaron Lanier, Evgeny Morozov, and Ellen Ullman. Or Fred Turner, Gabriella Coleman, and Sherry Turkle, to name a few from the academic flank.

But software criticism is not the same as technology criticism. A work of software criticism is to Nicholas Carr’s “Is Google Making Us Stupid?” what a New York Times book review is to Virginia Woolf’s “Modern Fiction.” The latter is a more synoptic assessment of the field, while the former is a focused interrogation of a single work.

So where are software critics? Like the rise of novels in the 18th and 19th centuries or jazz in the 1920s, isn’t software a defining artifact of our time? How in Turing’s name hasn’t a culture of software criticism emerged?

The idea that a rhapsodic exegesis of fermented grape juice could be a legitimate category of criticism didn’t gain traction until the likes of Robert Parker—whose legacy is, for the record, quite messy—made the genre serious. There had been wine reviews published in trade magazines, but there was no culture of wine criticism. Now there are more wine columns than (alas) poetry sections in major US newspapers.

Think wine is too different from software? Here’s another example for you: car criticism. In 2004, Dan Neil of the Los Angeles Times won the Pulitzer Prize for Criticism for his “one-of-a-kind reviews of automobiles, blending technical expertise with offbeat humor and astute cultural observations.”

Next up, architecture criticism, whose bona fides are well established. On this much we should agree: A piece of architecture can be as complex as a piece of software. In fact, the vocabulary of software engineering has many parallels to architecture. (The most obvious? Those who make high-level design choices are called software architects.) It may be no coincidence that Mumford, an early technology critic, served as the architecture critic for The New Yorker.

If grape juice and cars and buildings merit critical analysis for their complexity and design, shouldn’t a piece of software qualify as an object of criticism too? It’s a truism that great books, and insights extracted from them, help you understand society better than your own daily living experience. But so can products of engineering, like the Ford Model T, Boeing 747, and—a textbook example—the Singer sewing machine. The Chrome browser, which spans all layers of abstraction—from low-level network protocols to memory optimization to product features to UI elements—is surely no less complex an object than a Mini Cooper?

We cannot come to a full understanding of our time without certain pieces of software. I recoil at this phrase, but software (like it or not) has been eating the world. And large language models are coming to eat your lunch. Hence critical knowledge of software products is vital.

When explaining the success of Slack, business analysts might look at market forces and demands (“product-market fit,” in their lingo), but a software critic would evaluate software-specific aspects—user interface, frontend, backend, infrastructure. That critic might advance a thesis that Slack succeeded because it became what was thought to be unattainable by enterprise software: “likable.” Then the critic could look at its design elements, not only visual ones but its signature Knock Brush notification sound, and assess its risky yet fruitful backend rewrite—rejection of the conventional wisdom that you should never rewrite your code—that made it go from being the butt of an industry joke to a scalable piece of software.

Software critics would help us answer this simple question that demands complex answers: “Why is this good?” Or, often more entertainingly, “Why is this so bad?” Take Microsoft Teams as an example. What commentary we get now is a fusillade of tweets or rage threads in r/MicrosoftTeams. But a software critic could nail the underlying malady and establish a rational basis for its terribleness. A good work of criticism is liable to make you love the software you hated and hate the software you loved.

So what would a piece of software criticism look like? At its most basic form, a rough blend of product review and literary criticism. But it’s much more than that. The critic will anatomize the subject from several angles. Befitting the hybrid artifact that is software, they will adopt disciplinary anarchy, toggling from the commonsensical to the technical to the historical to the philosophical.

Let’s pick Google Docs as the patient zero of this new enterprise. A software critic may begin with some requisite cultural commentary on the labor of writing but then also provide a technical (even geeky) history-cum-explainer on how the operational transformation technology of Google Docs paved the way for real-time collaboration tools in other fields, such as Figma for design or Colab for programming. And how conflict-free replicated data type could make real-time collaboration the default mode of the future. Then the critic might explore what that means culturally and sociologically.

Here’s what software criticism must not be: No ratiocination similar to Parker’s point system for wines. No “buy on Amazon” links. A software critic could stand anywhere on the spectrum, from technological enthusiasm to optimism to skepticism to pessimism, but would need to avoid the extremes. They should sail between the Scylla of tech utopianism and the Charybdis of Luddism in order to invite all kinds of readers and avoid setting off ideological alarms.

And surely we can use some exciting prose! Burn that copy of On Writing Well and help yourself to some Nabokov soup. Exorcise the kind of homogenizing language that abounds in the rationalist blogosphere of Scott Alexander wannabes and avoid sounding as if the text were generated by a large language model trained on VC tweets. Self-medicate with William H. Gass, luxuriate in Lydia Davis, mainline Martin Amis, hallucinate with Geoff Dyer, get drunk on Peter Schjeldahl, and detoxify with the sobering yet adrenalizing eloquence of Parul Sehgal. We aren’t writing a damn readme here.

Even if it remains a niche area of criticism—isn’t criticism a niche genre to begin with?—the effort would be worthwhile. I’m reminded of what the music critic Alex Ross wrote, in a piece on Debussy, about what happens when a new creative form is born: “Debussy accomplished something that happens very rarely, and not in every lifetime: He brought a new kind of beauty into the world.”

SHEON HAN (@sheonhan) is a writer and programmer based in Palo Alto, California.

This is the first installment of WIRED Software Review. Read more at WIRED.com.

Subscribe to WIRED for just $5. Get unlimited access to WIRED.com, plus free stickers!

SUBSCRIBE