The hardware, software, and firmware of our places
How I think about what “placed-based” means
One year ago, I started this to explore how we shape the places around us and how they shape us. Over the past twelve newsletters, I’ve explored moments of big change, downtown futures, how place is a type of tangible memory, adages for public policy, as well as some other topics I’ve linked throughout this newsletter. It has become a monthly tradition with its own rhythm of moments of joy and stress. Most importantly, it has helped me build the time to practice reflection and to use a part of my brain that is less frequently used in my day-to-day work. And your feedback—which has come through a surprising number of live discussions—has helped sharpen and shape this writing more than I imagined. Thank you!
One buzzword that is a part of much of my practice is “place-based.” It is usually followed by nouns like “policy”, “initiative” or “strategy.” “Place-based” is one of those terms that is self-defining enough (approaches that are based on a place!) such that it can often be used in grainy ways that I imagine may mean different things to different people. As I put together the most recent set of newsletters about successful approaches to economic vibrancy, I’ve found myself thinking about a simple—but hopefully useful—analogy for conceptualizing what “placed-based” means; perhaps our places function like computers, with hardware, software, and what I’ll nerdily call firmware.
Hardware, software and firmware of place…so placewares?
These are not new terms to you; your physical computer is the hardware, what runs on it is the software and the software that controls the hardware is called the firmware. This same structure can map to the places we inhabit. The hardware is our built environment—streets, buildings, pipes, and bridges. The software is the life that uses the hardware—the people, the communities, the soft connections that bring us together as humans. And the firmware is the stuff that connects the two: the rules, regulations, and policies that we create to regulate our environment.
I have three short examples to illustrate this.
First off is St. Louis’s Cortex Innovation Community, an innovation district I wrote about in the last newsletter, which started me down this line of thinking. I realized there are the physical components of Cortex itself. This is the hardware of converted warehouses, research buildings, a park, a transit station, roads and bike lanes, and even the Ikea. Then there are the people and institutions that inhabit and animate the district. This is the software that includes BioSTL, Washington University, entrepreneurs, funders, and very cool facilitators. And lastly, the policy layer helped bring all of these together. This is the firmware of the tax increment financing district, zoning, governance agreements, land assembly rules, and incentives. I realized as I wrote the last newsletter that all three elements came together to foster a successful initiative that continues to grow and evolve over time.
Once I saw these ideas in St. Louis, I realized they work in various contexts and across various urban systems. As the chair of the DC Public Library Board’s Facilities Committee (a reminder that I am a big fan of our public libraries), I deal a lot with the hardware of our system. As a member of the board, I am also in touch with the software of how the library buildings are programmed and used. And our facilities master plan or our code of conduct policy? That’s the firmware. Each of these components plays an important role in a successful system.
The last example is housing, which I think is both most complicated and exemplifies the tension between the different lenses. There are those who emphasize housing as a unit that is created, maintained, and counted (hardware). Others focus on housing as a home where a person lives, finds stability, and builds community (software). And there are people like me who geek out on housing as a system facilitated or hampered by policies like zoning, finance policy, and building regulations (firmware). We cannot have successful housing outcomes without all three of these.
Ok I get it…so what?
These examples illustrate show how various systems rely on all three “placewares.” This framing has helped me better identify the various lenses that different people may have on the same problem. Each component has its various groups focused on that space. If I were to write a children’s book for my toddler about this, I would say engineers, architects, and planners are the kinds of professionals who work on hardware. People like teachers, social workers, religious leaders, and barbers tend to the software. And lawyers and policymakers focus on the firmware. By identifying these lenses, it is easier to create bridges across what can become silos of misunderstanding.
As an urban planner, I often focus on the built environment or the policies like zoning that help create it. When urban policymakers talk about fixing cities, they can get fixated on the “sticks and bricks” of hardware. It’s exciting to solve a problem that has a clear physical incarnation. And these successes get the ribbon cuttings, the social media hits, and coverage from what is left of local media. Who isn’t excited by the new shining library, the new bridge, or the grand opening of an affordable apartment building? Indeed, I have spilled some ink over the inspiration of our physical places. And even the hidden parts of hardware get amazing podcasts dedicated to them.
The software side is less tangible, but just as critical. Building a new school has a clear set of steps that is more or less the same everywhere and has a clear end point. Yet nurturing a successful school with strong student achievement cannot follow a project plan or GANTT chart. And even if success is reached, it must be continually fostered as there is no discrete “finish.” COVID-era downtowns showed us that strong physical assets don’t create vitality without the software of human activity and energy. And I saw in St. Louis that economic development coalitions which focus on coalitions and organizations can be bolstered by a clear connection to the physical place.
Each of these elements also has different time horizons, which can create tension. The buildings we build will often last through many generations of human use and policy frameworks. One of the challenges of DC’s post-COVID downtown was that many mid-20th century buildings were built for one thing: offices. They have large floorplates and concrete floors with embedded post-tensioned steel cables that make it very difficult to cut holes in for all the water and sewer pipes needed for other uses. The firmware of zoning codes that may have initially served an important purpose of separating industry and housing during the industrial era can calcify a city generations later by preventing much needed housing, thereby robbing a community of vibrancy.
This analogy certainly has its limits. For example, while computer software runs on computer hardware and is constrained by it, I think in the real world, our built environment serves the unbound creativity and possibilities of humanity. We are not boxed in by our buildings as software is by its hardware.
Even so, when applied to urban policy work, this framework can be useful. It has helped me articulate how, at this moment in time, when many of my neighbors are thinking a great deal about DC’s economic challenges, I see an opportunity to marry the software of an economic pivot centered on our communities with the hardware of a focus on physical areas in the city that is supported by the firmware of a city and regional policy agenda. It’s yet another way for me to stay hopeful in these times.
Thanks again for reading! Here’s to another year of exploration—and to the layers of cities we’ll keep peeling back together.
