Preamble
In this series of vignettes, I describe some design principles for technologies that follow nature. In short, such technologies would be self-limiting, accessible, cyclical, and purposeful. My hope is that technologies that follow these principles will lead to a greater unity between art and science, between intuition and reason, between nature and machine. Each would nurture the other.
Thanks to Jonathan Harris, Neri Oxman, Mario Schlosser, Simin Kamvar, and Angie Schiavoni for reading drafts.
– Sep Kamvar, May 2012
Self-Limitation
Surf and Silicon
I moved to Palo Alto in 1999, at the height of the first dot-com boom. I was at Stanford, which felt like the epicenter of it all. Every week I would hear about a hot startup or new technology trend. It was an exciting and frenetic time.
On the weekends, I would go surfing in Santa Cruz, about an hour south of Palo Alto, where the pace was different. One day, I was talking about all of this to a man who had been surfing at Pleasure Point for 40 years.
You have everything you need right here, he told me. Look at it. Good surf, good friends, this sunset. The problem with having a lot of stuff, he said, is that at some point the stuff starts ruling you.
Mastery
A recurring theme in science fiction is the idea that one day, our technologies will become self-aware, grow their population, and take over the world. Of course, humans will still be around, otherwise there’s no story, but they will be second-class citizens to the tools that they invented.
I've often wondered why self-awareness always comes first. Perhaps it's because it makes for a more interesting storyline. After all, a technology doesn't need to be self-aware to be self-reinforcing.
A couple of years ago, Nielsen ran a study that showed that the average teenager sends more than 100 text messages a day. Adults might get startled or nostalgic when they hear this, but the kids, for the most part, are happy. They like being in touch with their friends, and are not so concerned about the fragmentation of their attention or their dependence on their devices. Their phones are an extension of themselves.
If there were a textbook example of a viral technology, SMS may be it. Its use facilitates its spread. People get texts, and they respond. The responders then at some point become initiators, and the story goes on. Eventually, even the kids who don't want to be attached to their phones don't have such an easy choice. In a culture where everybody sends each other 3000 texts a month, you get left out if you only send 30.
There is a story of Bill Joy asking Danny Hillis what he thought about the scenario in which humans one day merge with robots. Danny responded that the changes would come gradually, and we'd get used to it.
That's the way it is with technology. We get used to it. I will get older and sound like a Luddite when I suggest that a hundred text messages a day might be too much. That will simply be the pace of modern life.
When the mechanical clock was invented, one of its early uses was to set the arrival and departure times of factory workers during the industrial revolution. At the time, people hated the idea of getting to work at a certain time; it felt like the ultimate victory of machine over man. Now, it's seen as responsible behavior.
But if aliens come from outer space and see people wake up grudgingly every morning to the beeping of an alarm clock, they might wonder who is the master and who is the tool.
Natural Limits
Inside of each of us, there are about 10 trillion human cells, and about 100 trillion bacterial cells. By cell count, we are only 10% human.
Given how outnumbered we are, it's surprising that we don't die more often from bacterial disease. You might expect that, of the hundreds of species of bacteria that live inside of us, at least a few would have the habit of getting out of line and growing at our expense.
We can give credit to antibiotics for saving us, but I think that would miss the point. Even before antibiotics, a surprisingly small number of people died from bacteria considering how many of them we host. And if we could invent an antibiotic that would get rid of all bacteria, we wouldn't want to. Our bacteria help us digest our food, store our fats, produce our vitamins, and train our immune systems.
The truth is that we are not alive in spite of the hordes of bacteria that inhabit us. We are alive because of them.
To me, one of the most startling and beautiful properties of our bacteria are their intricate mechanisms for keeping themselves in check. Let's take, for example, bifidobacteria. This species of bacteria lives in our gut and secretes acetic acid, which in turn breaks down the carbohydrates we eat and protects us from certain infections. Remarkably, and luckily for us, the acetic acid produced by our bifidobacteria also keeps them from growing out of control. When the environment gets too acidic, they don't reproduce.
Perhaps I shouldn't be too surprised by this feat of selflessness. Relationships tend to develop a rich texture as they mature, and us and our symbiotic bacteria have been going at this for some time now. I'm reminded of an older couple, where both partners have their quirks, but each knows how far to go, when to pull back, and what to tolerate; where each knows the other so well, and is so dependent on the other, that it's hard to tell where one person stops and where the other begins.
The relationship between us and our tools is newer, like a younger love. It's fiery and exciting, and we're still trying to figure out our boundaries.
Our tools, like most things, have natural limits to their utility. Up to a certain point, e-mail makes us more efficient. After that, the mounds of e-mail in our inbox take time away from our real work. Up to a certain point, time spent on social networks brings us closer to our friends. After that, it takes away from time we spend with them in person.
Our bacteria can offer us some wisdom here. If we want tools that respect their natural limits, we can design limitation into the tools themselves.
If the idea of self-limiting tools seems antithetical to technology and capitalism, let me suggest that we already build them. A search engine is a self-limiting tool. As is an online dating site. When these tools succeed, people leave the site. Video games and TVs, on the other hand, are self-reinforcing. Their use doesn't lead to disuse; their use leads to more use.
The more self-reinforcing a tool is, the more we likely we are to use it at our own expense. On the other hand, the more self-limiting a tool is, the more likely it is to die out.
The key is to find the balance.
Accessibility
Production by the Masses
In 1930, Gandhi spent 8 months in the Yerawada Jail in western India. During that time, he invented a new spinning wheel that came to be known as the Yerawada charkha. The Yerawada charkha is one of the more beautiful pieces of technology I’ve seen; it’s elegant, easy-to-build, and efficient.
Gandhi made the spinning wheel a linchpin of his independence campaign. And it worked. By spinning their own cloth, poverty-stricken villagers gave themselves a source of income and spiritual sustenance. They freed themselves from their dependence on the British textile industry. And they spawned an ecosystem of trades and tools, from weaving to dying to washing to carpentry, that restored vibrancy to the villages.
It has always intrigued me that Gandhi spent so much time thinking about technology. I understand the wisdom of it, but it’s rare to see such tool-centric activism. It would be like today’s leading civil-rights leaders urging their constituents to learn how to program mobile devices.
So I find it ironic that Gandhi’s critics labeled him as anti-technology, although I can understand why they did. Gandhi fiercely opposed expensive technology. And at the time, modern technology was expensive technology. If you opposed the factory, you opposed modernity.
But what Gandhi understood is that tools are most useful to the people that own them.
And villagers didn’t own factories.
What Lies Upstream
We use tools to build our tools. We use an ax, a hammer, and a saw to make a cabin, and we use Python, Django, and Apache to build a web service. These upstream tools are crucial in shaping our society. A world with no hammers would have no houses.
Most upstream tools are so ingrained in our culture that we often forget that they are tools, like our languages, educational systems, markets, and governments. But it is important to remember that these are tools, and as tools we can shape them, rather than passively allowing them to shape us.
Our tendency as toolmakers is to want upstream tools that are powerful. I’d argue that it’s more important to have upstream tools that are accessible.
By all accounts, Oracle is a more powerful database than mySQL. But if only one could exist, I’d prefer mySQL. Because mySQL is free — for use and for modification — it fosters a broader ecosystem of builders. It enables anybody with time and knowledge to build a tool to fix a problem they see in the world. It allows people to build things using mySQL and regift them to the developer community. We would not want a web that’s shaped only by those who can afford Oracle.
When upstream tools are only accessible to a few, our tools are more likely to foster monoculture rather than a vibrant ecosystem, subservience rather than self-determination. This is why Gandhi advocated the spinning wheel over the textile factory. And it’s why people don’t want WalMart in their community, money in politics, or barriers for startups. In the same way that we don’t want a web that’s shaped only by those who can afford Oracle, we don’t want a world that’s shaped only by those who can afford factories, or lawyers, or senators.
The web, for the most part, gets this right. Most web services are built on top of free operating systems, databases, web servers, and programming languages. They are marketed by accessible tools like Facebook and Twitter and Adwords. And they are often funded by accessible funding sources like YCombinator, or Kickstarter, or by sales through App Stores. The pace of innovation on the web, and the outsized role that software has played in shaping our lives, is in large part because these upstream mechanisms for production, distribution, and financing are more available than they are in other industries.
This suggests a guiding principle for makers: Look for upstream tools that are powerful, and work to make them more accessible. Square and AWS are nice examples of this. So are inexpensive 3D printers.
The corollary to this principle is: Look for upstream tools that are accessible, and make them more powerful. The recent efforts around JavaScript, like Crankshaft and processing.js, are nice examples here.
Like the sun, our upstream tools should be accessible and empowering to all.
Cyclicality
The Cuckoo and the Wildflower
The Great Spotted Cuckoo is a nomadic species of bird that lays its eggs in the nests of the smaller European Magpie. If the magpie host removes the cuckoo’s egg from her nest, the cuckoo ransacks the nest and destroys the eggs. When the baby cuckoo hatches, the magpie feeds it along with her own chicks. But the baby cuckoo is bigger, takes more food, and will often kill the magpie chicks by pushing them out of the nest.
Of course, this is dangerous, not just for the magpie, but for the cuckoo itself, who will at some point run out of nests to invade. In contrast, consider the wildflower, that reproduces by providing pollen to bees and butterflies and nectar to hummingbirds. One spreads quickly at the expense of the ecosystem that sustains it. The other spreads slowly, as a side effect of nourishing its ecosystem.
When we build our tools, we should aim for the latter.
Software Ecologies
If we're ever feeling smug about our position at the top of the animal kingdom, it is humbling to consider that we live in the company of more than a quadrillion ants. For each person on this earth, there are a few hundred thousand ants, bustling about, foraging for food, building complex structures. At least by the numbers, the ants are winning.
To me, ants are fascinating for another reason. They challenge our concept of self.
An individual ant is a feckless creature. It wanders around aimlessly, seeming to have no ability or purpose. But when you get a lot of them together, it's like alchemy. They transform into creatures that astound us with their intellect.
I remember reading an article a few years ago about how ant colonies eat. The authors studied 20 colonies of green-headed ants, and described a remarkably elaborate feeding process that can best be described as a collective mouth and gut.
The food for each colony was collected by worker ants, exactly according to the needs of the colony. The workers extracted the carbohydrates, which they could eat, and then fed the remainder to the larvae in the nest, who require high-protein diets. The larvae ate and then fed the remainder back to the workers, who could better digest the processed protein, and anything left was taken out of the nest by the workers and dumped as waste.
The process is so reminiscent of digestion in higher-order animals that it makes you wonder, which is the organism: the ant or the colony?
If I were to try to describe the mechanism for the emergent intelligence in ant colonies, I might use two words: communication and gift. A passage from E. O. Wilson's novel, Anthill, describes this nicely:
"The members of the Trailhead Colony transmitted their messages using about a dozen chemical signals, which they picked up by smelling one another constantly with sweeps of their antennae. An ant who was well fed said to a less well-fed nest mate, Smell this, and if you are hungry eat. If the ant approached and was in fact hungry, she extended her tongue, and the donor ant rewarded her by regurgitating liquid directly into her mouth."
Thinking about ants and their networks of communication and gift, I can't help but think of the internet.
In 2005, Paul Rademacher reverse-engineered the JavaScript code for Google Maps, wrote a program to scrape Craigslist apartment listings, and overlaid the Craigslist listings on Google Maps. It was the first web mashup.
It's hard now to appreciate how clever that was at the time. Today, most web services offer free APIs, and it's common for people to use multiple APIs to build something more intelligent than any of the individual services. APIs serve as a mechanism for communication and gift.
In retrospect, web services and APIs were a logical extension of blogs and RSS. What one did for text, the other did for software. This is common in the history of technology. New paradigms tend to start in technologies that are cheap to build, and spread to technologies that are expensive to build. They spread from text to software to hardware.
By that token, I imagine we will soon see more hardware APIs. Our phones will communicate with our cars, and our cars will communicate with our home thermostats. People will build hardware controllers that combine multiple APIs to coordinate our devices in surprising and thoughtful ways.
But that is an easy prediction. To see a further into the future of hardware, we might look at what's happening with text today. When we look at Twitter and SMS, we still see communication and gift. But more strikingly, we see smallness.
If software follows content, I imagine we'll start to see lots of APIs that do small things. But they will easily interact with one another to together do big things. And if hardware then follows software, I imagine that we will see lots of small devices that do simple things alone, but complex things together. They might remind us of ants.
Missions and Metrics
There is an old Zen story about a man riding a horse, galloping frantically down a path. His friend, who is sitting by the side of the road, calls out "Where are you going?" The man replies: "I don't know. Ask the horse!"
When we build our tools, we often depend on metrics to guide our development. We keep graphs of unique visitors and pageviews and watch them closely. This keeps us honest. It's hard to convince anybody that we're building a useful tool if our metrics show that nobody is using it.
But we must take care when we use metrics. Metrics can be like the horse in the old Zen story. Once we decide on them, they have a habit of setting the agenda. As the old adage goes, what gets measured gets managed.
The standard metric for a country's economic welfare is GDP. I find this strange. If the government decided to give millions of dollars to the country's richest people so that they can buy yachts from one another, that would increase GDP. So would clearcutting our national forests to build strip malls, outsourcing the raising of our children, and incarcerating large swaths of our poor.
If we temper the language a bit, we might find that this description is not so far from reality.
My point is that metrics shape behavior. Joseph Stiglitz describes this mechanism nicely: "What we gather our information about, and how we describe success, affects what we strive for." Political leaders who want to grow the economy, he says, will focus policies on things that increase GDP, even when GDP does not correlate with societal well-being.
Which brings me to my second point: all metrics leave something out. Often, they leave the most important things out.
In 2007, Stanford offered a course called "CS377W: Creating Engaging Facebook Apps". The course assignment was to build a Facebook application that, according to the course website, would "focus on solving a problem for a broad audience." It was an intensively metrics-driven class, and the key metric was user numbers. By the metrics, the results were astonishing: in the course of the 10-week term, the apps collectively reached 16 million users.
The flipside was that the applications themselves were underwhelming. Most of them allowed users to do things like rank the attractiveness of their friends, send virtual hugs and have virtual pillow fights. The substance of the applications reflected what the metric left out. If it were possible to measure the value of a user's attention, or how enriching an application is to her life, the course projects would likely have been quite different. But sometimes, the important things can't be measured.
It is useful, therefore, to have missions to balance our metrics. Of course, each tool should have its own mission. But if I were to suggest one mission for all tools, it might be this:
Every tool should nourish the things upon which it depends.
We see this principle at varying levels in some of our tools today. I call them cyclical tools. The iPhone empowers the developer ecosystem that helps drive its adoption. A bike strengthens the person who pedals it. Open-source software educates its potential contributors. A hallmark of cyclical tools is that they create open loops: the bike strengthens its rider to do things other than just pedal the bike.
Cyclical tools are like trees, whose falling leaves fertilize the soil in which they grow.
At the top of the stack, all tools depend on nature and human nature. They depend on the sun, trees, minerals, and fossil fuels to provide their raw materials and energy. They depend on the creativity of builders to give them form. And they depend on the attention of their users, without which they would languish.
An ecosystem of cyclical tools would therefore nourish nature and empower people. A fully cyclical software application may, for example, use peer-to-peer data centers powered by its users, consisting of biodegradable, fertilizing microprocessors. It would be open-source and provide APIs to empower the creativity of builders, and a clean design and useful purpose that cultivates the concentration of its users.
If some of this sounds like science fiction, so did manned lunar vehicles in 1950, or self-driving cars in 2000. We have a tendency to achieve what we focus on.
It’s difficult to build cyclical tools because the alternative is so tempting. Cars are faster than bikes. FishVille reaches more people than Moby Dick. At first, cyclical tools appear to be lower-power, slower-growth, and more expensive than extractive tools.
But you can’t measure the impact of tools on their own. You must measure them by the ecosystems that they co-create.
Purpose
Heart and Head
The great scientists of Ancient Persia were also artists. Omar Khayyam was an astronomer and a poet, Ibn Sina was a medical scientist and a poet, and Shaykh-i Baha’i was a mathematician and an architect.
Today we see this less. Artists are mostly artists, and scientists are mostly scientists. And generally, our technologies derive from science. Since science aligns with the head, and art aligns with the heart, understanding the heart and the head helps us to understand our modern technologies.
Our heads cultivate reason. Our hearts cultivate intuition.
Our heads seek opportunity. Our hearts seek purpose.
Our heads maximize utility. Our hearts give gifts.
Our heads think of self. Our hearts feel connection.
Today, our technologies reflect reason and utility and opportunity and self. But this may be an artifact of our time. We could equally imagine building technologies that reflect intuition and purpose and gift and connection. I might say we're already starting.
The Nature of Computer Programming
The twig girdler is a species of beetle that lives in Texas and Northeast Mexico. When the female is ready to lay her eggs, she finds a mimosa tree, crawls onto a branch, chews a slit into it, and lays her eggs. But her larvae can’t survive in live wood, so then she backs down towards the trunk, chews a groove around the branch, and the branch falls off. She then flies away and a few weeks later, her eggs are hatched and her larvae feed on the dead wood of the branch. What’s most amazing is this: a mimosa tree, unpruned, will live for about 25 years. A mimosa tree, pruned by twig girdlers, can live for over 100 years.
How this complex, beautiful relationship came to be is one of the mysteries of evolutionary biology. The odds of getting to it just from random mutation and natural selection are slim.
But we don’t need to understand the mechanism to characterize the effect. The effect is as if the beetle has some intuitive sense of the world around her, as if the beetle and the mimosa tree are connected, as if they both exist with the unique purpose of helping one another by offering to one another life-affirming gifts.
We see this again and again in nature. It is as if everything in nature acts out of the properties of the heart.
It’s OK that we don’t yet understand the mechanism. I’m reminded of something that Feynman said about quantum physics: “I think I can safely say that nobody understands quantum mechanics. So do not take this lecture too seriously, but just relax and enjoy it. I am going to tell you what nature behaves like. If you will simply admit that maybe she does behave like this, you will find her a delightful, entrancing thing. Do not keep saying to yourself, if you can possibly avoid it, ‘But how can it be like that?’ because you will get down the drain, into a blind alley from which nobody has escaped. Nobody knows how it can be like that.”
I make this point because I want to draw a distinction between biomimicry -- which examines the mechanisms of nature and attempts to replicate its apparatus in technology — and the kind of technology that I’m proposing. The most powerful qualities of nature are those where we don’t yet understand the apparatus. We don’t fully understand nature’s wisdom, her purpose, her intuition, her connection. But we can mimic these qualities without understanding their mechanisms, because they parallel the qualities of the heart.
If we want to build technologies that follow nature, we will motivate them from the heart. Of course, we will use our heads to make them work. But our choice of the tools we build — and the attitude with which we build them -- will come from a place of gift and purpose and intuition and connection. In this respect, we will be artists as well as scientists.
I think the best programmers understand this. Don Knuth, who wrote the book on programming, pointedly called it The Art of Computer Programming.
In his 1974 Turing Award lecture, he said: “My feeling is that when we prepare a program, it can be like composing poetry or music. Furthermore, when we read other people’s programs, we can recognize some of them as genuine works of art. I can still remember the great thrill it was for me to read the listing of Stan Poley’s SOAP II assembly program in 1958; you probably think I’m crazy, but at the time it meant a great deal to me to see how elegant a system program could be. The possibility of writing beautiful programs, even in assembly language, is what got me hooked on programming in the first place.”
And Bill Joy, who built vi and BSD (both of which are still used some 30 years later), once wrote about how Michelangelo released statues from the stone, carving as if he were discovering the form rather than creating it.
“In my most ecstatic moments,” said Joy, “the software in the computer emerged in the same way … I felt that it was already there in the machine, waiting to be released. Staying up all night seemed a small price to pay to free it — to give the ideas concrete form.”
Gift Economies
When people talk of gift economies, often they talk about them as a replacement for the market economy. But gift economies and market economies have operated side-by-side for much of history. Child care, until recently, was exclusively a gift economy — neighbors would babysit one another’s kids. The creative arts and science have historically been gift economies, and to a large extent they still are. And today, free, open-source software sits alongside ad-supported and paid software.
To me, the most interesting examples of gift economies are when they exist alongside money economies within the same organization. I think this points to where the world is headed. Craigslist doesn’t charge for any of its services other than job postings. Google places advertisements on a small fraction of its result pages. Both companies understand that gifting most of their services leads to short-term costs, but long-term viability. But to think about it this way doesn’t do justice to the real story.
The real story is that their founders thought of the gift first, and the means of supporting it second.
The Heart of the Builder
Over the past few years, there has been a meaningful trend in the design community towards user-centered design. As with any methodology, it’s valuable to a point. User-centered design is great for designing a new toaster. But it’s not so useful in designing, say, the World Wide Web. If you asked people in 1989 what they needed to make their life better, it was unlikely that they would have said that a decentralized network of information nodes that are linked using hypertext.
The danger in user-centered design is that it releases the designer of the responsibility for having a vision for the world. Why have one when we can just ask users what they want? But this is a very limiting mindset. The user sees the world as it is. Our job as builders is to create the world as it could be.
It’s not that users are not less intelligent than builders. They just tend to underestimate the possibilities of a technology, and therefore suggest incremental changes. Other than Mark Zuckerberg, there were few people in 2004 who saw that Facebook could become an operating system for the web. Instead, most of its users had ideas on customizing the profile page, or sending event invitations, or whether or not to allow high school students to use the site.
There is another reason to avoid relying on your users to design your tool. The most elegantly crafted tools are those where the purpose of the tool aligns with the purpose of its builder. So the key to building great technologies is to first find your purpose. And you will not find it by polling your users.
Instead, you might be better served to spend time in places where you can see reflections of yourself. The best surfers I know seem to have a sense of exactly where the next wave will be. They craft a style about their surfing and their life that seems to come directly from the water. Artists that I admire seem to be quiet and quiet and quiet, and then come up with something beautiful, as if the beauty came from some relationship with the silence. And the great programmers I know are always taking breaks from the screen to go walk in the woods, as if they receive the most difficult parts of their programs by osmosis, and then just go to their desk to type it up.
Natural technologies arise from the heart of the builder, from a place of gift, from an intuition and purpose outside of oneself. There is something beautiful about the fact that spending time in nature helps get us there.