A software system is a living organism.

The metaphor of a living system gets bandied about a lot in software engineering. Often it's in the pejorative sense — something we say in exasperation but don't really (really?) believe.

Well it's all true. Software systems are alive and evolving, for all intents and purposes.

The recently-coined adjective "teleonomic" describes a system that evolves and changes but does not pursue any specific goal. A waterfall is one example of a teleonomic system. The water and the landscape beneath it both had to arrive at a very specific point in space and time in order for a waterfall to exist in that spot, at that time. The predictability of the waterfall's behavior make it a thing. Waterfalls are durable, permanent. Yet the waterfall has no sense of self — it does not "want" or "need" to exist. Yet it persists and further, adapts to changes in its environment.

Christopher Alexander (the proto-architect of object-oriented software design) characterized the sense of living permanence in a place as "the quality without a name (QWAN)." "Teleonomic" is a scientific term that means the same thing as QWAN.

A teleonomic system is a system that is living and interacting with its environment without necessarily being "alive" in the sense we learn in Biology class. A flock of birds is another example of a teleonomic organism. The birds certainly are alive in the classic sense, but how to describe the flock which is not itself alive and whose existence depends on the undirected cooperation of numerous birds? Flocks of birds are teleonomic.

Software systems do not plan, they do not think, they do not remember the past. But everyone knows: they act like they do. And it turns out that science says: yes, for all intents and purposes software acts like it's alive because it is alive. Software systems are observed to act like living organisms because they are teleonomic systems.

Until the 21st century everyone thought of software as a mechanical product "constructed" out of bits. Software is assembled, tested, shipped and replaced. For four decades the industry labored under this assumption. But after living with "home computers" for a generation, people started to realize that software isn't so much assembled as it grows and then sticks around. No one expected COBOL to be running in production 60 years into the future. No one predicted the love people have for their old devices. Because no one expected people to respond to software the way people respond to living things.

But now it makes sense. Software programs tend to stay in existence once created. And people tend to form deep lasting relationships with software. And that's good. That describes Google and Apple, for a start. And that's Nintendo and Amiga, too. Those systems live and we live with them.

All software has that living quality. Not just at 3am when the server acts like it's trying keep you awake. Not just when Nagios eerily picks exact worst moment (again). Today, software engineers are starting to listen to their systems all the time, not just during emergencies. Listening to our systems all the time is called "Normal Failure Theory" and it's the philosophy that at the heart of the devops movement.

Software systems do, for all intents and purposes have teleonomic "minds of their own." And most of the time, they do the right thing. Sometimes they do things we don't want. Sometimes they try to teach us things. Far from being a factory product, software has turned out to be a living collaborator. The challenge of computer science in the next 50 years is to learn to trust and learn to listen.