In this post, I’d like to share some highlights (and some of my own comments) about an episode of Freakonomics Radio titled In Praise of Maintenance (published October 20, 2016).
Personally I was delighted by the episode’s topic, given that several of the roles I find myself enjoying (see my About page) align themselves with the concept of maintenance. The technology (and software development) industries also grapple with this issue, so I felt inclined to share what I’ve learned.
From the episode
The genesis for the episode was an essay from Aeon titled Hail the maintainers: Capitalism excels at innovation but is failing at maintenance, and for most lives it is maintenance that matters more. The authors Andrew Russell and Lee Vinsel propose that “our culture’s obsession with innovation and hype has led us to neglect maintenance and maintainers.”
The podcast host, Stephen Dubner, phrased things another way: It’s about taking care of what you’ve already created.
The authors of the essay weren’t advocating a maintenance-only approach. You need a balance of innovation and maintenance; it’s a shift in value away from only the new/shiny towards labor, work, and sacrifice.
Larry Summers had this to say: “People always think more about how new ground can be broken than they think about how existing institutions can be sustained or existing facilities can be maintained. It leads to a constant trap where we under-invest in old things, then old things disappoint us, then we feel a need for new things, then to satisfy that need for new things we under-invest in old things, and the cycle goes on.”
Harvard economist Ed Glaeser took a historical approach to maintenance by speaking about the Roman sewage system. Cities require a great deal of physical infrastructure maintenance because proximity to others is such an issue. For example, roads are shared, people live closer to one another so theft becomes easier, etc. Glaeser cited Singapore as being impressive in terms of city-scale maintenance. “As the world becomes more complicated, as infrastructure becomes more complicated, there are more ways that it can potentially go wrong, and maintenance, if anything, becomes more important.”
Vinsel addressed engineering specifically, as such a large portion of effort is spent on maintenance: “Having entrepreneurship and innovation as the message, that we’re just kind of skewing reality for young people, and we’re not giving them a real picture, and we’re not valuing the work that they’re probably going to do in their life.”
With government-funded physical infrastructure, things can get trickier. Every four years, the American Society of Civil Engineers produces an infrastructure report card on physical infrastructure. The most recent report card didn’t have high marks; some examples include solid waste (B-), transit (D), roads (D), drinking water (D), and bridges (C+). It should be noted that there could be bias in an organization that is asking for more money from the government to suit its own needs. On the other side, the longer we wait to get around to fixing things (e.g., Kennedy Airport), the more expensive it will be.
From Dubner, “One of the promises of technology is that it would eliminate the need for much, or in some cases all, of that kind of hand-made maintenance.”
Historian of science, Ruth Schwartz Cowan spoke about domestic maintenance. Her book (More Work For Mother: The Ironies Of Household Technology From The Open Hearth To The Microwave) posits home inventions that were supposed to make things more efficient led to more labor. “There are two components of work: time and metabolic labor.” Most of the new technology saved us metabolic labor. It was harder to wash clothing when you were scrubbing it manually and hauling the water. With the advent of appliances, housewives began to spend more time doing their chores (e.g., post-World War II, we wash clothes more often). People are doing a “double day” where they’re doing as much maintenance work as their grandmothers might have done. They’re doing almost as much unpaid maintenance work as paid work (by hours).
Bringing things back to the technology industry, Martin Casado, a partner at venture capital firm Andreesson Horowitz, said that growth companies spend about twice as much on research and development than other companies. As companies mature, the majority of the investment is in maintenance, driven by pressures from the public markets. Legacy enterprises grow by purchasing innovations (i.e., buying startups). The public market knows that if you’re a mature company, you’ll keep the lights on to get predictable returns. We have a bifurcated system, where venture capital and startups are the ecosystem that takes the risks.
Dubner reminded us that there’s so much infrastructure around us to keep things moving; we only notice it when there are failures.
My comments
As I said at the beginning, this episode resonates deeply with my values and strengths. In my industry, maintenance work is at best boring/un-sexy, and at worst treated like a second-class citizen (i.e., work to be done by someone, as long as it’s not me).
Early in my career I watched a multi-part soft-skills presentation series by Brian Prince; one such episode was “Don’t Be a Plumber.” The premise is that you should only write code that helps your company make money or cut costs. “So, every piece of code that anyone can write, then we call that plumbing. We call that infrastructure. It’s not strategic in nature.” As Ruth Cowan mentioned in the podcast, her late husband said, “Plumbers run the world.” If you’re working on something non-trivial, you need infrastructure. Someone has to build and maintain that. There’s probably an analogy to be made when comparing new/shiny to maintenance as there is when comparing super-vocal developers to dark matter developers. We need a balance of both.
A final thought I’ll share about maintenance as it pertains to software development, is that we’ve become so accustomed to moving quickly (e.g., deploying 30 times per day) that maintenance takes a back seat in terms of priority. Maintenance in this case could also include making code maintainable. This reminded me of risk compensation: “people typically adjust their behavior in response to the perceived level of risk, becoming more careful where they sense greater risk and less careful if they feel more protected.” For example, drivers are more likely to be less risk-averse as compared to decades ago while driving because cars have more safety features. Likewise in software, why bother building it well when the cost/speed of building something else is low? Just get it out there – we’ll fix it later.