Let’s be clear. Technology criticism is nothing new. Modern technology criticism, depending on who you ask, goes way back to Lewis Mumford, Herbert Marcuse, Martin Heidegger, and Marshall McLuhan. More recently, I assume you’ve 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 to name a few from the academic flank, Fred Turner, Gabriella Coleman, and Sherry Turkle. 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—in theory, at least, if it existed—is a focused interrogation of a single work. So where are software critics? If the 18th and 19th centuries saw the rise of novels and the 1920s was reserved for jazz music, isn’t software a defining artifact of our time? How in Turing’s name hasn’t the culture of software criticism emerged? The idea that a rhapsodic exegesis of fermented grape juice could be a legitimate category of criticism hadn’t emerged 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 (some with obvious conflicts of interest) but there was no “culture” of wine criticism. Now, there are more wine columns than (alas) poetry sections in major newspapers in the United States. But you may think that wine is too different in form from software. Then 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.” And here would be to present the case of architecture criticism, whose bona fides are well established. On this much we should agree at the outset: 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. (For example, those who make high-level design choices are called software architects.) Many concepts are shared as well. Take the interface-implementation divide in software. Similarly, all elevators share the same interface—the door opens when you press the button, you wait for it to arrive and enter, you press the button of the floor you want to go to, and so on—but their implementations—hydraulic, geared traction, machine-room-less—vary. It may be no coincidence that Mumford, an early technology critic, served as the architecture critic for The New Yorker. What is software if not the most consequential form of creation of our time? In fact, it’s possible that we cannot come to a full understanding of our time without certain pieces of software. (Can you explain the early 20th century without Tin Lizzie?) 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 a critical understanding of software products—ones you spend more time every day on than calling your parents every week—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 may only evaluate software-specific aspects—user interface, frontend, backend, infrastructure—and advance a thesis, for example, that it succeeded because it became what had been thought to be unattainable by enterprise software: It was “likable.” Then the critic could look at its design decisions—not only visual ones but its signature Knock Brush notification sound—and assess its risky yet successful backend rewrite—rejection of the conventional wisdom in the software industry that you should never rewrite your code—that made it go from the butt of the industry’s joke to a scalable piece of software. Why hasn’t the culture of software criticism emerged? A simple explanation is that the form is still young. Books, poetry, buildings, and wine have been around for millennia. Cars and films have been around for more than a hundred years. Yet modern software is only a few decades old. Also, the form is under-theorized—not engineering-wise but humanities-wise. If we were to compare it again to buildings, it’s as if there’s a strong civil engineering tradition without architectural theory. Another obvious reason is that there’s not much crossover between people in the humanities and in engineering. And given how lucrative being a software engineer can be, there’s not much incentive to become a software critic. 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 we get now is a fusillade of tweets or rage threads in r/MicrosoftTeams. But a software critic can nail the underlying malady and establish a rational basis for its terribleness. Conversely, a good work of criticism is liable to make you love the software you hated and hate the software you loved. By reviewing their work, perhaps we can finally recognize open source programmers without whose tireless work our infrastructure will collapse. And I’d love to see talented independent developers—who create thoughtfully designed applications (without which my life will collapse) and sell for a reasonable price but live at the mercy of the App Store—celebrated. And perhaps to broach sensitivity territory, over the past few years, technologists and those in the writing profession—broadly encompassing journalists, critics, and non-sci-fi fiction writers—have developed trust issues. After the groovy days of the post-dot-com bubble era that lasted from the mid-2000s to mid-2010s, the “techlash” (not my phrase) has become the dominant theme. Given the animosity between two groups, you may think that this won’t be a space where both parties will participate in. To this point, the writer and neuroscientist Erik Hoel recently wrote a post titled “2022 was not the year of consilience,” about how C. P. Snow’s Two Cultures have grown more antagonistic towards each other. But perhaps that’s why software criticism is needed more than ever in the midst of the brinkmanship between the two worlds. Software criticism may be one of the ways to inch toward an armistice. In the demonology of some media outlets, “software engineer” occupies the same rank as “investment banker,” and in certain circles in the Bay Area, the word “journalist” is uttered like a slur. But that both sides are engaged in a shady enterprise is a corrosive belief. So what would a piece of software criticism look like? A rough blend of a product review and literary criticism? At its most basic form, yes. But it’s much more than that. The critic will anatomize the subject from several angles. Befitting the hybrid artifact that is software, the critic will adopt disciplinary anarchy, toggling between the commonsensical to the technical to the historical to the philosophical. Instead of speaking in abstraction, let’s pick Google Docs as the patient zero of this new enterprise. A software critic may begin with some requisite cultural history on the labor of writing, but then also provide a bit of technical (and even geeky) history-cum-explainer on how the operational transformation (OT) 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 the research in conflict-free replicated data type (CRDT) could make this mode of working a default mode of collaboration in the future. And what that means culturally and sociologically. Now, here’s what software criticism must not be like. No ratiocination similar to Parker’s point system. This is also not a place for affiliate links. No dollar-motivated boosterism nor thinly guised advertorials. A software critic could stand anywhere in the spectrum ranging from technological enthusiasm to optimism to skepticism to pessimism but need to avoid extreme ends, meaning they should deftly 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 with some Nabokov soup. Exorcize the kind of homogenizing language that abound in the rationalist blogosphere written by Scott Alexander wannabes and avoid sounding as if the text were generated by a language model trained on VC tweets. Self-medicate with William H. Gass, luxuriate in Lydia Davis, mainline on Martin Amis, hallucinate with Geoff Dyer, get drunk on Peter Schjeldahl, and detoxify with the sobering yet adrenalizing prose of Parul Sehgal. Anything goes. Well, everything except the Zinsser-ized, over-sanitized—hence sterilized—technical prose, because we aren’t writing a damn README here. So who can be a software critic? To say that everyone’s a critic would be an easy cliché, but you don’t need a PhD in media theory or know how to implement a Bloom filter in C. Technical expertise helps, but what’s needed is technical literacy. Dan Neil was no car mechanic and neither was Mumford a civil engineer. And I’m sure Robert Parker can’t tell the difference between the chemical structures of ethanol and those of methanol to save his life. Of course, it doesn’t mean that practitioners are excluded. Remember that Le Corbusier was influential both as an architect and a critic. In the beginning, software critics will need to sort out some idiosyncrasies of this new literary form. Here’s one. Unlike a book or a film, a piece of software is never finished, hence numerous and ugly-named versions (e.g., v2.5.3 or 1.0rc1) How do we deal with that? Perhaps we can take hints from wine and car critics who evaluate different vintages and model years. Or we can do what restaurant critics do: Revisit a few years later. In fact, those are some of the most memorable ones. (Pete Wells’ reviews of Per Se and Peter Luger come to mind). Software critics also need to start imagining how to critique backend frameworks and operating systems that don’t have visual elements. I don’t expect the New York Review of Software to be published any time soon. But when the form matures, we could imagine a NYRB-styled comparative review of books with similar themes—a group review of email clients, for example. But who knows, when this form is fully realized, there might be Softwareforum like Artforum and Bookforum (RIP). Even if it remains a niche area of criticism—but, to be fair, isn’t criticism a niche genre to begin with?—the effort would be worthwhile. I’m reminded of what the music critic Alex Ross once wrote, in his piece about Debussy, on what happens when a new creative form is brought to existence: “Debussy accomplished something that happens very rarely, and not in every lifetime: He brought a new kind of beauty into the world.”
