Here’s a great interview. I was able to speak with Shannon Mattern—Professor of Anthropology at the New School for Social Research—about her book, called “The City Is Not A Computer: Other Urban Intelligences.” This book, released in the US in August 2021, examines what the “city” is (or isn’t), who the city is for, and what makes a city “smart” (or doesn’t).
The book was published at a precarious time, not only for publishing but also for cities themselves. COVID-19 had decimated budgets and tourism dollars, and commuting for work or for fun permanently changed, and continues to evolve. The city was no longer a place for commerce and industry. COVID, in many ways, cocooned the city into a husk of an economic place. What directions could it go?
But we haven’t lost the thread—at least not totally because a city is not a computer. The city is so much more. It’s an aggregate of the people and the things that make it. It’s a vessel for creativity and humanity. It’s a series of iterations and do-overs and building blocks for people to learn to live. And the pandemic helped to build these alternate synapses. We’ve got a lot of learning to do. Shannon’s book peers into the city as empathy, the city as equity, and the city as equanimity. Let’s dive in.
This interview has been edited for clarity and length.
I am currently a professor of anthropology at the New School in New York, but before my current position, I spent 15 years in media studies. I have written about the ways that we design information into the world, and how the ways we know the world has materialized through various design practices—from interface design to architecture to urban planning.
The book we’re here to talk about today is my most recent book, which was published last August  by Princeton University Press. It’s called “A City Is Not A Computer.”
One of the things I found interesting was that you’re not trained as a city planner. Anthropology and city planning and urban sociology are very closely related and that’s one of the major themes that I’ve tried to establish in my blog in the last two years or so—people come to this field from all different places, but we all are trying to eke out and figure out the way that cities can work for all of us.
I’m curious about the origin of the book. Where did you get the idea to write this?
I have been a columnist for Places Journal for the past decade now. It’s an open-access journal for public scholarship about architecture, urbanism, and landscape architecture. It started decades ago as an academic journal, a partnership between MIT and Berkeley, then spun off into its own nonprofit. I’ve written close to three dozen long-form pieces for them over the past decade.
The journal has a relationship with Princeton University Press; the Places Books imprint features small, affordable, pocket-sized books. And I was invited to revisit some of my published articles and remix them into a short-form book. I asked online, on Twitter, which of the themes I’ve explored in my articles seem to resonate most for people, and the topics related to urban data and urban intelligence seem to rise to the top.
There are four chapters in the book, plus an intro and a conclusion, but they’re not just reprints of four pieces that I’ve written before. I rewrote a lot of the older material that had previously appeared in the journal and added a lot of new material. Given that a lot of the stuff I’ve written for Places is about timely issues—ongoing smart city projects, new proposals for urban interfaces, and urban data projects… these things tend to age pretty quickly, as does a lot of tech reporting and tech scholarship. I wanted to reframe his of-the-moment periodical writing as lasting questions that are more appropriate for a book, which has a longer lifespan. I asked myself: What does the “book” form allow you to do?” You can talk about issues as more enduring concerns.
“A City Is Not A Computer” is one of the first texts to marry “smart cities” with the ongoing COVID pandemic and epidemic. I’m curious to know how COVID, and our inability to effectively use the city as a connected network during the last couple of years, affected how you approached this book and the updating of the articles.
I had been invited to propose the book before COVID, and then when COVID happened I asked, “Does the world even need this book?” When I decided I should proceed—with encouragement from my editors and potential readers—I wondered what role COVID should play in the book. I didn’t want it to be a book about the city in the age of COVID, but I did want to acknowledge that the pandemic has reprioritized/reframed a lot of the questions we’ve been asking about the role of technologies in cities; what cities are for; what unique value that urban form has to offer to humanity. So COVID did provide a philosophical and historical context for a lot of the questions I was asking.
But I didn’t want the book to be about COVID.
I wanted to say that the pandemic was certainly a turning point; it re-inflected a lot of the questions we were asking before. We now have to ask those persistent questions in light of what we’ve learned over the past two years–and are still learning.
Where did the concept of the “city as a computer” come from?
Throughout my academic career, I’ve written about the relationship between spaces and information: network geographies, media-driven architectures, data-driven planning, data repositories, libraries, and so forth. The idea that the city is an information processing machine, or a space that draws on computational design methods, is not new. Cities and architectures have always been communicative environments.
In my book from 2017, “Code and Clay, Data and Dirt: Five Thousand Years of Urban Media,” I looked at cities’ entanglement with information processing and management that has existed for the entire history of urbanity. Thus, the idea of a city being a computer is not only not new to my work, but also it’s not a new idea at all.
There are plenty of historians who look back at the deep history of urban intelligence and data-driven planning. Think tanks, like the RAND Corporation in the post-war period, had to find a new market for their services after the war, and they focused on the rising “war in the city,” or urban street warfare—which was often a code for racial unrest and class disputes. Historians like Jennifer Light and Orit Halpern have written about this. But the city-information history goes much deeper than that–back to the ubiquity of printing and urban-reading publics, to the role of writing in urban management, to concerns with acoustics in the ancient urban public sphere.
The specific article that became the titular article for the book arose because, six or seven years ago, I was invited to write a book chapter about how the city is an information processing machine. As I began to write it, I realized, “Yes, it absolutely is”—but it’s so much more than that because the types of intelligence that matter in a city cannot always be reduced to information, and they can’t always be processed by a computer. So, I wrote an article, perhaps provocatively, whose thesis was the opposite of what they asked me to write: I wrote about how the city is like a computer, but it’s so much more than that. That became the article, “A City Is Not A Computer,” which then became the focal point of the book.
To extend the metaphor, would you then say that people are the “bits of information?”
The “city-as-computer” metaphor has resonance in multiple disciplines. It resonates with computer scientists or artificial intelligence experts, ecologists, and urban planners. Each of those different disciplines might conceive of the role of the human differently: in some cases, particularly those that are driven by more behaviorist approaches, the human is a product of nudges and environmental stimuli. The human there is almost machine-like in its responses to provocations that we can design into the environment. To ecologists, the human is just one mode of existence within the entire ecology where multiple species and nonhuman entities exist symbiotically or non-symbiotically with one another. Computer scientists might regard humans themselves as walking computers communicating with this larger computer of the city.
The human plays a different role with different forms of agency and different forms of intelligence, depending upon which disciplinary framework you’re drawing from.
The first chapter in the book called “City Console,” addresses the processing of information and the centralization of data. Is there an alternative to the panopticon/centralization idea to have a functional city?
I wanted to start the book with a case study that crystallizes a lot of the theoretical and critical questions that I would be asking throughout the book. The urban dashboard seemed to be the perfect object lesson because, again, I had written about it before, but also because it seemed to be something that people were intimately familiar with. Heat maps and COVID dashboards became so ubiquitous during the early stages of the pandemic. The dashboard had become a pandemic “mode of existence.” It became newly familiar to everybody
Then I asked: what are the alternatives to having a control room or a dashboard that purports to aggregate all the things that are measurable in a city? The second half of the book is intended to provide a couple of different alternative ways of thinking about how intelligence exists in a city that cannot necessarily be dashboarded.
I use the library as one example. This is not to say that libraries themselves and other knowledge institutions don’t use dashboards, because they do—they use enterprise software and circulation management systems to run their services. But if we think about the variety of intelligences and ways of knowing that are embodied in a trusted social institution, like a library, its way of conceiving intelligence is much more capacious than what can be measured and displayed via a dashboard.
The same thing with the final chapter—I talk about maintenance and care, which requires a huge amount of lived, embodied intelligence. We could have a dashboard within the sanitation department pointing out what trash bins need to be emptied or at a city transportation agency, and what roads need to be repaired. We could dashboard and map where action needs to happen. But the knowledge that maintenance workers and other caregivers possess to do their work is not often articulated or able to be translated into an algorithm. Care and repair, in particular, are often things that people learn through years of practice, apprenticeship, and interacting with people; it’s often a form of intergenerational, distributed, embodied knowledge.
We could also look at the idea of “embodied cognition,” which some cognitive scientists and philosophers are thinking about, where intelligence is something that doesn’t exist in individual brains—it’s something that is distributed within our environments. We look at examples of things like slime molds, starling murmurations, or schools of fish. Intelligence doesn’t exist in the brains of individual entities, it’s something that exists in the synthesis between all these different entities.
One example at the end of the first chapter that hooked me was the way you talked about Patrick Geddes and how he used a survey and a panoptic vista to start to understand how a city “works.” Sometimes landscape architects call this view the “transect.” Taking a step back and seeing a city is important. We can see very up close, but we can also see very far away.
Was this example a way to humanize and rationalize the end of that chapter?
Something that I’ve heard from a couple of Silicon Valley people is, “This isn’t a tech book.” I’d respond, “Well, that’s good, because that’s not what it was meant to be.” It’s called “the city is not a computer.” But if it is sort of a “tech book,” it’s encouraging us to think more capaciously about what constitutes technology: it’s not just data, it’s also sidewalks. It’s the extensions of man that McLuhan talks about. It’s historical forms of technology that have not been superseded by data but whose use has been transformed as newer gadgets arrive. We could even say that trees, if we think of them as tools to think with, can be considered technologies as well. This is not to say that trees’ “reason for being” is to be technologized by humans, but if they become tools to think with, they do, in a way, become conceptual technologies for us.
It was absolutely intentional for me to think about how we network bodies in tandem with one another and with trees—all these different ways of looking at how intelligence is networked and distributed in an environment.
One of the concepts that you bring up in your book is the urban “graft,” the idea of building new on top of old. Where is the disconnect between the technologists and the business leaders who want to build on existing work to exploit more profits or create more networks within their sphere and this alternative obsession with building from scratch?
Building from scratch is not a new idea. We’ve had the idea of tabula rasa development for centuries, if not millennia. The roots of a lot of colonial conquests are exactly this: raze what exists both physically (topple the buildings) and culturally (ban traditions, burn the libraries), so that the colonists can start anew.
The value of the “graft” model might be more apparent when we consider it in relation to some of the other metaphors I explore in the book. There’s also the idea of the “platform.” “Cities as platforms” can be generative and exciting when we think about an environment as a stage for development and innovation, with all the tools and resources provided for us to build upon. The challenge with the platform approach is that it doesn’t encourage us to think about what lies beneath the platform or how it was built, or what history lies beneath. What is the infrastructure underneath the stage that establishes its realm of “thinkable thoughts?” What ideologies are below it; what is the history that produced it? What engineering makes it stand up?
I proposed the “graft” as an alternative, drawing some inspiration from Christopher Alexander‘s idea of the city not being a tree. There are also a whole bunch of different ways to graft: the industrial, agricultural graft, which is a mechanized process. We could think about graft as an artisanal, thoughtful practice, where we’re considering the essence of a species and what it means when we meld two different species together. It requires an understanding of what constitutes the rootstock–what was there before–and how we honor it and responsibly add to it. What are the “modes of being” of the different species that we’re putting in this new relationship with one another? How do we most effectively, humanely, and ethically suture them together?
If we think of “grafting” as an artisanal process, it requires much more engagement with what was there before, which, with the platform metaphor, is often plastered over.
In my practice, we call those context-sensitive solutions, where we’re not just trying to jam the best practice into a project, outside of its context. We’re trying to do some deep engagement with our community.
I’ve never thought of engagement as an “artisanal process” before—it’s really interesting because that’s really what it is: approaching the individual, and asking them what they think. That’s maybe as artisanal as we can get in terms of human interaction, one on one.
To bring back the computer metaphor, are our leaders wired like this? Do you think to lead a city or to lead the development and growth of a place, are they wired to think about the tabula rasa? Are they wired to think about big visions? Is that how our politics are set up?
I certainly don’t want to offer a blanket statement, because I’m sure we can think of some city leaders who offer alternative visions and alternative approaches. It has occurred to me that it takes a certain type of ego to even put oneself forward to say, “I can lead this city, or I can be President!” So there has to be some degree of grandeur, or some totalizing vision, to even compel somebody to step forward into a leadership role.
Leadership is also a huge, messy challenge that one takes on. To feel that they’re doing an effective job, a leader has to have a sense of the breadth of challenges that they’re responsible for. This is where something like a dashboard becomes appealing because it gives a tangible sense of this challenge. Hoving in a blimp or drone over the city doesn’t necessarily give one an omniscient, panoptical view of its macro-scale challenges. And when we focus on this all-encompassing vision, we lose sight of lots of on-the-ground, local challenges.
This is in part why tech companies have been so successful in selling their wares to urban administrations: because it promises totalizing visions and ways of monitoring, in real-time, all of these urban systems that are instrumentalized and rendered measurable.
The scale of the challenge and the difficulty of having one’s finger on multiple pulses across the city renders these inclusive computational models and platforms appealing solutions to be sold to city leaders.
I had a conversation with someone recently and she said transit tech is one thing that can unite people who are in deep disagreement about solutions going forward. The technology itself can be parametrized and can “hold” a lot of our disagreements because technology is apolitical—it doesn’t hold political leanings. Of course, it’s not apolitical because the decisions behind the algorithm or implementation are very much political.
Removing the human necessarily from an equation is a thing that a lot of our leaders are interested in doing because it’s simpler to just point to a solution from being outside one’s own politics…and one’s opposite politics.
Do you have any thoughts on the technological tabula rasa, say a new mapping software that helps a transit agency optimize its headways? Maybe the “algorithm” can proxy for making unpopular decisions about cutting service, say, where a leader can easily point to the technology: “It’s just what the software is telling us to do.”
Even the choice to listen to the software, to follow its lead, is a political choice. The design of the software is based on a host of political choices. policy and best practices come from political choices people have made, determining what to prioritize, and how to model an urban system. These are epistemological and political choices.
A mayor might find comfort, for instance, in being able to outsource often messy, ethically fraught, politically-charged questions to software. This is also perhaps why consultants are sometimes very appealing as well because if we have to ask hard questions about how to either sustain a business or make it more profitable, we turn to the consultants and outsource those difficult choices, which often result in people losing jobs and budgets being cut. It seems that some software has taken on the historical role of the McKinseys and the BCGs in that it allows for the convenient outsourcing of difficult questions.
We can apply this metaphor to autonomous vehicles, too. If there’s no driver responsible for operating the vehicle, who is then responsible for the operation of the vehicle? Is it whoever writes the algorithm that says “turn here” or “avoid this pothole there?” Is it the limited-liability company that signs off on it?
How does insurance work?
These are decisions that we’ve been punting down the field. MIT has an interesting website called “The Moral Machine,” where an algorithm offers two impossible examples of impending crashes and asks the user to make a choice of which one is more “desirable” or the least “non-desirable.” Framing matters. It’s the trolley problem.
I’m curious about your thoughts on autonomy and the future of our cities as “computers” through that lens.
Well, this is not my area of expertise. That said, this is perhaps where the layered infrastructural models and ecological models I talked about in the book could be useful. Just as there could be distributed intelligence, there is also distributed responsibility and obligation. It’s not only the person who wrote the algorithm; it’s also the person who’s engineering the car; the people who are doing the civil engineering; it’s also the urban administrators who decided that this is where we want to invest our money. We also have the marketers who are selling visions to the general public and to the people who hold the purse strings, who can make these decisions.
This is a distributed form of intelligence, which makes it difficult to regulate and pinpoint a specific site of intervention or a point of failure. Because any challenges we face or benefits we reap are the product of a complicated, entangled system—like the roots of a forest. The metaphors of distributed intelligence in a city are a good way to think about how beautifully and messily entangled a lot of these concerns are.
Were there any other “city as blank” metaphors that you were considering outside of the ones that you put forward?
I write about this in the second chapter of the book, which is taking up the title “the city is a computer,” looking historically at the metaphors we’ve used: the city as a “machine,” the city as a “steam engine”, the city as “whatever was the technology was of the day, conveniently adopted to think about complex systems.” It applies not only to cities but also to brains: we have people talking about brains as” steam engines,” brains as “machines,” brains as “computers.” Anything really complicated and so beautifully complex that it’s somewhat inscrutable tends to attract a lot of these metaphors that are drawn from the prevailing schema in contemporary culture.
There are a whole host of metaphors, tied to their particular historical context, that have helped us to make sense of these complex environments.
One of the foundational books for me and how I think about my practice is Marshall Berman‘s “All That Is Solid Melts Into Air.” His main thesis is this idea of the Faustian bargain: the idea that to grow, we have to make an impossible bargain with ourselves and with our communities. And we do it. And we continue to do it. What do we trade? What do we give up for “growth?” Who wins? Who pays?
This reminded me of this idea of maintenance in the fourth chapter and this idea that we don’t focus on rebuilding things and we don’t necessarily focus on the internal complexities of the next iteration of a thing. Look at our Subway system in New York and its billions in maintenance and upkeep backlog…and yet we’re limping along, building a new, expensive, necessary line.
I understand these are two different pots of money. And we all have to do all of it—design, build, operate, maintain, etc. Why don’t we prioritize maintenance in cities?
I wrote a separate article a couple of years ago, connecting maintenance to degrowth: this idea that maintenance, which could aid in growth-based practices, is especially well-suited to thinking about alternatives to growth as our supposed telos, or end goal. Growth: not only making the city bigger, making GRDP bigger, but also this pursuit of the comprehensive, exhaustive dataset, or this desire to turn everything into a trackable data—that, too, is a form of growth. We see both the growth of the data apparatus and the growth of an ambition to be uber-sentient, omniscient monitors of everything.
These principles also map onto discussions of climate change: this idea that to address the crisis, perhaps it’s not a matter of growing systems, but maybe a matter of cutting back on certain things. If we keep measuring the upward arrow–more, bigger, faster–as the line of progress, perhaps such an index is inimical to solving challenges, like climate change, for instance. Among the reasons that maintenance is not always appealing is that it’s often about preservation rather than growth or innovation.
Harvey Molotch talked about the “growth machine”; we’ve naturalized that as well. But ”bigger is always better, more is always better” is not always the case. Degrowth—and new archaeological and historical and ecological research arguing that cooperation and conservation, rather than competition and destruction—can remind us that growth has not historically been the sole pursuit of humanity, nor need it be for us
There’s this pursuit of reversing entropy and trying to measure everything. And the question is when you get to the end of the measurement—what’s there? People can’t even decide on an approach to figure out a problem oftentimes and they’re offering solutions? It’s backward thinking.
It’s very disheartening that we’re so focused on a big number ($1 trillion for infrastructure?) that people can’t conceptualize and we’re not even focusing on the development of feedback loops and agile, iterative systems that help us create or maintain.
This is related to the work of the Center for Urban Science and Progress, founded at NYU, which I’ve also written about. New York City was collecting all these data points and they didn’t know what to do with them. They needed an external organization to conceptualize the data’s applications and that’s where CUSP came in. At the outset, the growth of the data was an end in itself without necessarily knowing what we were collecting for.
Regarding the trillion dollars in infrastructure funding for something—where do we apply it? This is where I think computational methods can help. We just have to think about how to ethically and smartly and responsibly apply them in tandem with other methodologies and other ways of thinking. This is where I feel that ethnography and computational methods can be really useful together. Given the difficulty, any urban administrator or community organization faces in understanding the breadth of challenges that its constituents face, heat maps and data-driven models can be really helpful in finding where the hotspots are. On-the-ground approaches can then help provide nuance, and reveal the historical and cultural contexts, for what’s happening in those hotspots on the map.
There are challenges to this method as well because some critics have argued that data analysis through a racial lens–heatmapping crime or infrastructural collapse, for instance– tends to reinforce or reinscribe spaces of injustice. Looking at a map for high crime areas so we can identify “issues to address” tends to reinforce stereotypes about certain populations. That said, mapping, if applied responsibly, can be useful in assessing “Where do we now need to deploy more close-to-the-ground methods to figure out what’s happening here?” This is where the big data and the small data of more qualitative approaches can be used productively with one another.
That’s a step a lot of planning agencies and our development agencies skip. They go right from the big data—the hypothesis creation—into the solution and they don’t necessarily delve into the proof because there’s no deliverable necessarily associated with…listening. How do I justify to my boss’s boss spending 25 hours this week of expensive time going to a community center or just standing on the street corner and listening to people?
It’s a big challenge in the micropolitical sphere of the work environment at the City. And I’d love for that to change in my lifetime. But we’ll see.
Your term “deliverable” captures a mentality that seems to be tied up with these ideas of data instrumentality, this idea that you have to have a measurable thing at the end of a task. I try to address this assumption through the libraries chapter in “A City Is Not A Computer.” I chose this example in particular because I’ve been working with libraries for 20 years and because libraries are productively valuable-but-hard-to measure institutions.
How can we measure the value of a library to the community? Plenty of city leaders want to say “It’s an engine of economic uplift.” We can measure the increased paychecks of people who work through its programs; we can count the number of materials that circulate or the number of e-book downloads, or the bodies who come in, but there are so many forms of value that museums, libraries, cultural institutions, and community organizations provide that are not measurable–or not measurable in the timescales that are required by things like quarterly reports. More longitudinal, systemic outcomes are hard to pinpoint.
Do we have anything close to a library in terms of its flexibility as a place?
Well, I would say education, if we thought differently about education. So much of our education now is based on economic uplift: we measure the salaries of people when they get certain college degrees to determine the return on investment. If we thought about education instead as producing more curious, responsible, collaborative, civic-minded people…it’s really hard to measure those types of outcomes.
I’d also say parks. The social infrastructure, both programmed and unprogrammed, and the value they offer—the public health value they offer—is hard to measure with conventional methods. They offer tremendous value for public health, but they’re also pedagogical spaces. In a park, people learn about nature; people learn about sharing the commons; there’s lots of informal learning that happens in a park. If we appreciate all the activity that’s not formally programmed, but is informally, accidentally, and emergently happening in a park, these spaces are just as flexible and capacious and rich as a library.
Is there any work you want to plug or anything that you’re currently working on you wanted to share?
I share most of my work. I prioritize open-access venues for my writing, so nearly everything is already made to be shareable. I also make all my teaching material openly available on my website.
I will say that I’m currently working on a new piece for Places. It’s part of a new series they’re doing on repair. I’m writing a piece on the cultural history of the repair manual. I’m imagining how we could apply the “repair manual” model across multiple scales–from the technological object, to bodies, to communities, to urban environments. So how scalable and or non-scalable is repair, and how might a manual help us fix the various breaks and dysfunctions in our world?
This is our RSS Feed and this story was found here by our Project ADA. Make sure to visit the site and original post!