Monthly Reading, September 2021
Res Extensa #12 :: composability in tools for thought and the next internet, exaptation, construction standards, and Parkinson's law
This month we visit a number of interesting pieces on web3, charter cities, software, and other topics, including a couple of original pieces from my blog.
Composability is in the air these days with the expanding presence of web3 projects. It refers to the "lego block" effect possible with smart contracts, where project A can mix and match projects Y and Z, building a novel products that themselves can be reused in the next down the line. People call defi "money legos" for this reason — it allows developers to build their own "mods" on top of existing tools for staking, derivatives, and yield extraction.
In this piece Gordon Brander looks at composability in other software tools, likening what users build with composable protocols to open-ended evolution:
If a tool supports composition with other tools, it supports open-ended evolution. At that point, all of the other ways in which it might be terrible become incidental, because an evolutionary system will always be more expressive than one that isn’t.
I wrote this piece riffing on another of Gordon's posts on the concept of "exaptation." We learn about "adaptation" in elementary biology, where organisms adapt specific traits to serve a specific survival function. Exaptation is when a feature evolved for a particular function is repurposed for a totally different one — air bladders in aquatic animals evolved for buoyancy regulation, and were exapted to become lungs when moving on land; dinosaurs developed features for insulation, which were repurposed for flight in smaller creatures later on.
The same thing happens in technology and infrastructure. The internet harnesses a blanket of copper cables strung across the nation to make our computers talk to each other through audio. Derelict railroad rights-of-way are refreshed as extended bike trails. Clever exaptation happens all the time, and is worth exploring when we find opportunities for it:
Just like in evolution, technologies evolve slowly. When we're developing new technologies, protocols, and standards, we'd benefit from less green-field thinking and should explore what can be exapted to get new tech off the ground. Enormous energy is spent trying to brute force new standards ground-up when we often would be better off bootstrapping on existing infrastructure.
Brian Potter's Construction Physics is my new favorite newsletter. He writes about the business and history of the construction industry. Every post I've read so far is excellent.
The development of standards is a fascinating topic. Some industries seem overburdened with standards, tripping over their own feet to generate regulation and rules. Others seem to operate effectively enough with minimal official standards and go with a "this is just how we do things" handshake approach. As a person generally oriented to bottom-up, “discovered” standards, the idea of official committees meeting in rooms for years to develop top-heavy standards covering every edge case is anathema to my thinking, but I can see the benefits side of the balance sheet in certain cases.
Within the construction space, the "community of practice" is something I hadn't heard of before, but this article gives a fascinating look at how it works. Construction is far from lacking in official standards. But for a world so intricately complex with as many players as there are typically involved, there are a surprising number of loose standards and industry norms that lower coordination costs between the dozens of parties involved in a typical construction project:
But beyond documented standards, the industry is also strongly shaped by what Dubois and Gadde refer to as a “community of practice” - a combination of informal norms, widely accepted techniques, craft skills, and unspoken assumptions that together create a common set of expectations on a project. When a team comes together for a project, even if they’ve never worked together before, there will already be a shared set of expectations as to how information will be represented on drawings, the deliverables the project will require, who will have responsibility for what, how the different systems will interact, and all the other items that might otherwise require time, effort, and expense to coordinate.
The cost of shared knowledge is not free!
You've probably heard of Parkinson's Law. Originating from the work of naval historian Cyril Northcote Parkinson, it goes something like this:
In a project, the work to be done expands to fill the time available for its completion
Even if you haven't heard of it, you've definitely seen it in action. There's some sort of peculiarity of human behavior that gives us trouble with long-ish time horizons. Maybe it's the fact that thinking in long-term is a relatively new phenomenon, evolutionarily speaking (cro-magnon man wasn't all that concerned about retirement or running 5-year software projects).
If given resources and permitted to use them, they will be used.
I also liked here the additional detail from Parkinson's work, 2 additional points explaining the effect in the inflation of bureaucracy:
1. "An official wants to multiply subordinates, not rivals," and
2. "Officials will make work for each other."
Bureaucracies exist to carry out processes more than to achieve outcomes.
I wrote this a few months back, thinking about how the IKEA effect appears in the low-code software application space. Low-code is just an overused term of art referring to tools for making tools: software that empowers users to build their own things.
The IKEA effect says:
Consumers are likely to place a disproportionately high value on products they partially created
What role does the psychological pull here play in the popularization of low-code software?
Low-code tools express this effect, too, showing that customers are very willing to participate in the creation process if they get something in return. In the case of IKEA it's more portable, affordable furniture products. In low-code software it's a solution tailored to their personal need. Paradoxically, putting additional effort into a product through self-service, assembly, or customization generates a greater perception of value than consumer being handed an assembled, completed product.
I linked a few months ago to Scott Alexander's article on Próspera, an experimental startup city being built on a Honduran island of Roatán.
This is a solid overview of what the crypto movement can power, far above and beyond currencies and financial systems. Stephen McKeon covers DAOs, play-to-earn, learn-to-earn, oracles, and participatory governance. I learned about 5 or 6 cool new projects here.