In energy efficiency circles, the story of Jan Schilham’s 1997 redesign of a pumping system for a Shanghai carpet-making factory is famous. Schilham saved 92 percent of pumping energy and lowered capital costs by using a well-known principle: Pumping water slowly through fat, straight pipes reduces friction and saves energy relative to pumping the same volume quickly through narrow twisty pipes.
Why isn’t it always done that way? Because the bigger pipes cost more than the energy saving. Schilham’s insight was that energy is not the only payback. Fatter pipes lower the size of the pumps and motors required, so even with the additional plumbing expenses, total capital costs are lower. Energy savings in this context are free, or better than free.
In a narrow sense, this was an improvement in cost accounting, not technology. Nothing unknown or untested was deployed. No breakthrough enabled the lower costs — they’d always been possible. Schilham simply counted a benefit that had been overlooked, demonstrating that a technique usually considered unprofitable actually saved money.
The key that allowed Schilham to exercise his genius was that Interface carpets had already decided to reduce its ecological footprint drastically. “Whether” had already been decided — Schilham was worrying about the “how.” Essentially he was in the position of someone complying with a standards-based efficiency rule.
Another example is the fact that office paper use in the U.S. has actually dropped per capita since 1999. Unlike the Schilham example, this was driven by technical improvements, including some R&D. But the technical improvements were slow and incremental, and the R&D were closely tied to the third D, “deployment.”
One thing that contributed to this was that duplex printing became a standard feature in many high-end printers and copiers. Another is that computers and screens generally got better faster. Both these things are the result of R&D, but R&D in industries already actively involved in selling their product.
Another factor is that the publication of the book The Myth of the Paperless Office may have helped drive the document management industry to improve their software’s ability to do things it does well, and stop focusing on trying to develop features that will not compete with paper for at least half a decade. Deployed properly, document management software may not create a paperless office, but it can create an office that uses less paper, and do so as a side effect of improving productivity. It does this because developers now understand that computers can improve retrieval, sharing, and collaborative work on documents, but remain an inferior medium for reading long documents from start to finish. Computers are better for collaborative markup, but worse for editing by a single person. While they are better for retrieval based on key words, they are worse for intuition-driven searching through key documents.
Because most of today’s document management packages take account of screen viewing’s strengths and weaknesses compared to paper, they actually do reduce printing as a side effect of improving productivity. (Older versions mostly led to more printouts rather than fewer.) Note that, like computer hardware, software research and development is always closely tied to deployment and depends on user feedback. The most expensive part of that process is discovering and fixing bugs.
We sometimes hear calls for Apollo- or Manhattan-style research programs to achieve technical breakthroughs in solving the climate crisis. However, most of the technical improvements that would be useful in this regard are better discovered during deployment than in disconnected research projects. (While we have the technical capacity to phase out emissions today, we don’t necessarily have the capacity to do so with a minimum of undesirable side effects, or at the lowest achievable cost.)
I hope these stories illustrate why super projects along the lines of the Manhattan Project or the Apollo moon shot are bad models for improving greenhouse gas-reducing technology. The type of improvements we need are more likely to be discovered during deployment than in some separate mega-process that precedes implementing the huge number of solutions we already know about.
