This quick typology of tech journalism provides an incomplete catalog, but you get the idea. It includes news reporting on events such as layoffs, gadget reviews, company and founder profiles, opinion essays by renowned figures such as Zeynep Tufecki, investigative journalism like “The Uber Files”, industry digests from TechCrunch or personal blogs, Substacks and even Hacker News comments and GitHub issues if you’re feeling generous. Yet upon viewing this vast array of content there is a curious gap: software criticism in which pieces of software are subjected to critical analysis.
There is no denying that critique of technology has a long history. Lewis Mumford, Herbert Marcuse, Martin Heidegger, and Marshall McLuhan are all widely viewed as critical voices from the past. In more recent times political commentators and authors such as Jaron Lanier, Evgeny Morozov, Ellen Ullman and Fred Turner have published work related to this issue. Similarly, academic figures including Gabriella Coleman and Sherry Turkle’s research has also addressed technological criticism in depth.
It is important to note that software criticism differs from technology criticism. The New York Times book review is to Nicholas Carr’s “Is Google Making Us Stupid?” what a work of software criticism is to Virginia Woolf’s “Modern Fiction.” While the latter offers a broader overview of the field, the former, if it existed, examines a single work in greater depth.
The 18th and 19th centuries saw the rise of novels, while the 1920s were the era of jazz music. Isn’t software a defining artifact of our age?
In spite of the fact that Robert Parker has left a messy legacy, the idea that rhapsodic exegesis of fermented grape juice could be a legitimate criticism had not arisen until he made it a serious genre. There had been wine reviews published in trade magazines (some with obvious conflicts of interest), but there was no “culture” of wine criticism. Currently, major newspapers have more wine columns than poetry sections (alas).
If you think wine is too different from software, here’s another example: car criticism. Dan Neil, a critic at The Los Angeles Times, won the Pulitzer Prize for Criticism in 2004 for his “one-of-a-kind reviews of automobiles,” which merged technical expertise with offbeat humor and astute cultural observations.
It is clear that architecture criticism and software engineering share many of the same concepts. For example, those who make high-level design choices in software are called software architects, which mirrors the idea of an architect in architecture. Furthermore, the interface-implementation divide is a concept which is visible in both software and architecture. This perhaps explains why Lewis Mumford, a noted technology critic, could so easily transition to become the architecture critic for The New Yorker. Considering this relationship between the two, one can appreciate how complex a piece of architecture can be.
If grapes, cars and buildings require critical evaluation due to their complexity and design, shouldn’t a piece of modern software qualify for the same? It is often said that reading books, or the understanding derived from them, provides a better insight into the society than one’s own daily living experience. Engineering products such as Ford Model T, Boeing 747 and Singer Sewing Machine are capable of doing so too. Chrome Browser featuring layers ranging from low-level network protocols to memory optimization to product features and UI elements is no less complex than a Mini Cooper. Even Linux kernel hackers consider it an aesthetic object like a Swiss watch.
It is possible that certain pieces of software cannot be understood in order to fully comprehend our time. What is software if not the most consequential form of creation of our time? (Can you explain the early 20th century without Tin Lizzie?) I cringe at this phrase, but software has eaten the world, and large language models are coming to eat your lunch.
Therefore, you must have a critical understanding of software products since you spend more time on them every day than you do on your parents.
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.
Software criticism has not been widely established yet due to its freshness in the form of modern software, which is only a few decades old. Furthermore, this niche field lacks an intellectual backbone as there is an abundance of engineering knowledge but little theory through humanities. There is also a lack of crossover between the soft sciences and technology sectors which makes software critics rare find with the potential to gain financial rewards minimal.
The emergence of software criticism has been hindered due to its relative youth; modern software is only a few decades old whereas books, poetry, buildings and wine have been around for millennia. This form is also under-theorized in humanities as opposed to engineering. A lack of crossover between engineers and those in the humanities further contribute to this problem, with software engineers often being presented with lucrative opportunities that render unappealing the prospect of becoming a critic.
Software critics can be of immense help in determining the plusses and minuses of software such as Microsoft Teams. We often witness intense debates raging in social media or on subreddits, but true insight can only be gained by an expert. Criticism that is incisive and well-written, has the potential to turn our opinions about a certain software upside down – we might appreciate what we once loathed and dislike what had seemed appealing earlier.
Michael Sorkin, a renowned architecture critic, considers criticism a service profession imbued with moral and practical purposes. This type of intellectual exchange among creators, consumers and critics has the ability to enhance the art forms. A critic can also strive to bring attention to unsung artists or those still new in their fields. Similarly, software critics are able to raise awareness for independent developers who do not benefit from the press recognition of large tech companies.
In light of this, it would be nice to recognize the tireless work of open source programmers whose efforts keep our infrastructure afloat. Furthermore, we ought to celebrate talented independent developers who make my life a tad easier with thoughtfully designed applications sold for a reasonable price, yet still remain at the mercy of the App Store.
Considering the hostility between techies and those in the written word, it may seem almost impossible for both sides to meet halfway. However, Erik Hoel’s “2022 was not the year of consilience” explores how even with this animosity between C. P. Snow’s Two Cultures, collaboration is possible.
Software criticism is needed more than ever in the midst of a tense situation between two realms.It might be one step closer to forming an agreement. Often times, there is the idea that software engineers and investment bankers share similar standings, while journalists are viewed with disdain in certain Bay Area circles. This view that both career paths involve controversial activities contributes to a damaging mentality.
Let’s focus on Google Docs as the linchpin of this new venture. A software critic should supply some requisite cultural background on writing, alongside a technical and geeky history of OT technology that brings forth real-time collaboration tools like Figma for design and Colab for programming. Additionally, they could discuss the research into CRDTs and how this mode of working could easily become the normal form of collaborative work in future. This has implications both culturally and sociologically.
We can imagine an analysis of Notion that goes beyond recognising its minimalistic design. Looking at which UI/UX principles – potentially influenced by Douglas Engelbart and established by founder Ivan Zhao – and its own data model allow the app to maintain this aesthetic. It must be noted, though, that software criticism should not be rooted in a Parker-style point system, affiliate links or dollar boosterism. While it is possible for a critic to take either an enthusiastic, optimistic, skeptical or pessimistic stance on software, they should aim to occupy the middle ground between tech utopianism and Luddism in order to attract all kinds of readers without causing ideological tensions.
To craft an enthralling piece of writing, one should abandon the mundane On Writing Well and opt for a more flavorful Nabokov soup. Instead of conforming to the banality that pervades Scott Alexander’s blogoshere, strive to make your words stand out from the VC tweets-like verbiage. To help reach this goal, take inspiration from William H. Gass, Lydia Davis, Martin Amis, Peter Schjeldahl and Parul Sehgal—it can be a wild cocktail if desired. Yet it’s best to stay away from the overly- clean and sterile academic rhetoric that feels like a README file!
Naturally, this does not imply that practitioners are not included. Keep in mind that Le Corbusier had an impact as a critic and an architect.
Software critics will initially need to iron out some peculiarities of this novel form. This is one. A piece of software is never done, unlike a book or a movie, which is why there are several iterations with awful names (e.g., v2.5.3 or 1.0rc1) What should we do about that? Perhaps we might learn something from the wine and automobile reviewers who rate various vintages and model years. Alternatively, we may follow the example set by restaurant reviewers: Visit again in a while. In actuality, those are some of the ones I remember the most. (Reviews of Peter Luger and Per Se by Pete Wells come to mind.) The ability to criticize operating systems and backend frameworks without the use of visual components must also be considered by software reviewers.
The New York Review of Software won’t likely be released any time soon, in my opinion. Yet, as the form develops, we could envision a group review of email clients, for example, that compares books with related themes in the manner of the NYRB. Who knows, though; there may be a Softwareforum when this form is fully fulfilled, similar to Artforum and Bookforum (RIP).
The effort would be useful even if it remained a specialized field of criticism—although, to be fair, isn’t criticism itself a specialized genre?
When I think about what happens when a new creative form is created, I’m reminded of what music critic Alex Ross once said about Debuss: “Debussy accomplished something that happens very seldom, and not in every lifetime: He brought a new type of beauty into the world.”
