In college I had a wonderful art teacher named Jewett Campbell. He was a modernist painter, and he taught us to see our paintings as visions that emerged from the canvas. At every step of the way, we were told that our paintings must always have a kind of architectural solidity – a compositional wholeness.
We were told to start a painting with the most important macro-features, and gradually fill-in the details, catching the basic overall scheme within the first few strokes. And we were taught to appreciate the techniques of post-impressionist Paul Cézanne.
Cézanne would often stop a painting, leaving large areas of the canvas empty. Apparently, he could stop working on a painting at any time, and the integrity of the composition would be solid; balanced. The composition would hold up. Leaving so much raw canvas was Cézanne’s way of inviting the viewer’s inner eye to fill-in the rest.
Little did I know after studying Cézanne that…decades later…I would see software development in the same way.
Meditate on the Organic Whole
I don’t know about you, but as a developer, I really hate it when a software project gets pulled apart, with large components being rendered inoperable, while key parts are re-written. Would a surgeon kill a patient in order to do a kidney transplant?
Cézanne would never neglect one part of the canvas in order to obsess on another part. The big picture was always kept in his mind. Like a Cézanne painting, a body of software should be seen as a living being – a whole.
Now, let’s talk about chickens.
How is Cézanne Like a Chicken?
You see: a painting by Cézanne is like a an organism whose genes – whose full potential – is present from the very start.
Consider the way an embryo grows into an adult. The embryo of…say…a chicken, is a living thing; a moving, functioning, eating, breathing animal. At every stage of its growth, all of its genes are present. By the time it hatches from the egg, pretty much all of its internal organs exist in some rudimentary form.
(BTW – the picture above is actually a penguin. I think it’s kinda cute, don’t you?)
Usually, when I start a new project, or work with a team to decide on how to get a project started from scratch, I try to get a sense of what the main components will be.
Sometimes, a key component is sketched-in as a stub, like a splotch of gray-blue in a Cézanne painting that shows where an important cloud will be filled-in later. This cloud’s looming presence will set the mood and provide a compositional counter-weight to the mountain on the other side of the scene.
Oops – I forgot. We’re talking about chickens.
So, what if we considered the vital components of a software system to be the organs of an animal?
Are there other people who like to use biological metaphors when talking about software development? You bet:
Biological Metaphors in the Design of Complex Software Systems
Structural biology metaphors applied to the design of a distributed object system
Biological Inspiration for Computing
Here’s a piece on the Organic Metaphor, where the author says, “Industry pundits have taken to calling the process of software design “system architecture.” They borrow, of course, from the ancient and time honored tradition of construction.”
Later, the author says, “My experience is that the best programs aren’t designed. They evolve.”
Like building architecture, the organic paradigm is the most resilient, most evolvable, most sustainable way to ensure growth and longevity in software systems.
……
Organism = “Organ” + “ism”
“Modules” in biology are described by [Raff, R. A. 1996] as having…
- discrete genetic specification
- hierarchical organization
- interactions with other modules
- a particular physical location within a developing organism
- the ability to undergo transformations on both developmental and evolutionary time scales
Let’s look at these five requirements in terms of software development:
1. discrete genetic specification:
I’m tempted to compare this to Design. However, software rarely begins with a known genetic code. Perhaps “the evolution of a new species” is a better metaphor than “the development of an individual”.
In other words: the genetic blueprint of a software organism is pretty much guaranteed to evolve. And programmers are better off letting that evolve through prototyping, design iteration, unit testing, and user-testing – especially in the early stages of its life.
2. hierarchical organization:
Classes, Encapsulation, Method-calling, Inheritance. OOP OOP a DOOP.
Earth’s Biosphere invented Object-Oriented Programming before we came along and gave it a name.
My liver performs certain functions, and those functions are different than the functions that my kidneys perform. My organs communicate with each other using arrays of biochemicals.
3. interactions with other modules:
Data Flow, API’s, Interfaces
4. a particular physical location within a developing organism
This may only apply to visual code editing and file directory access. Software is made of bits, not atoms. We have to make it appear that it occupies space and time in order to bring it into existence.
If the software gets deployed in a distributed physical environment (a spacecraft, a smart house, or among an internet of things), then physical location does indeed apply. In this case, we’re not just talking about software anymore.
5. the ability to undergo transformations on both developmental and evolutionary time scales
Amen Brother!
That last one is the punch line. Besides having a healthy birth, how do we design software to scale across the development cycle? How do we make it evolve organically as teams of programmers come and go, or even as companies and open-source communities merge and transform?
I think mother nature has many more clues.
By the way, you may prefer to think of a body of software as behaving more like an ecosystem than an individual organism. Although, I would suggest (being a fan of Gaia Theory) that ecosystems are really just super-organisms.
Software is the most versatile, plastic, and evolvable brainchild of Homo sapiens. It will probably not go away, and it may even outlast us. In fact, software could even eventually become a new living layer on Gaia. It might have to be put to use to monitor and manage the health of the planet (as well as continuing to help people find funny cat videos).
An era of autonomous, evolvable software is predicted by Hillis, Kelly, Koza, and many others. But fully sustainable software – as a new digital species – won’t come about for a long time. Software is in its adolescence. It is still in its growing pains.
Earth...Brains...Technology...Design 