I’m slightly ashamed to reveal that I only recently became aware of the Unix Philosophy so-called (hat-tip to stud Josh Heling @jrheling). I say ashamed because contained in the Unix Philosophy are things I preach on a daily basis about how complexity can be achieved in human-made systems.
The two aspects I want to draw attention to here are the following related principles that are intended to be applied to basic program components:
Do one thing and do it well
Make interfaces clean and uncluttered to support composability
It’s no coincidence that Unix is one of the longest-surviving pieces of computing infrastructure (over 50 years!) — this development philosophy leaves little room for core improvements to be made.
Composability means that you can easily connect components together in various ways. The key idea here is that out of simple components organized into larger structures various ways, you can achieve emergent behaviors and properties that in combination can achieve something useful. This is a powerful idea in technical domains, but also in human domains when one considers how the people and teams in an organization interact with one another to solve problems: clean and explicit interfaces help clarify the work to be done.
In the Unix Philosophy, the things being composed are components that do one thing and do it well. I’m always looking to living systems to inform my view on functional (i.e. non-pathological) complexity, and my immediate reaction to this was that this is not what we see in biology. That doesn’t necessarily mean it is a bad or wrong approach, but I wanted to understand why they don’t square, or if they do, what I was missing.
In organisms we typically have many-to-many mappings with respect to structure and function: one function can often be fulfilled by different components (I can pick something up with my left or my right hand, or if necessary even my mouth or a foot), and one component can fulfill multiple functions (our tongues aid in the front-end of the digestive process, and have also picked up the handy function of helping us articulate speech for communication).
As is often the case when dealing with complexity, what initially looks like a contradiction is not one, once terminology and concepts are properly sorted. The confusion here comes from the phrase do one thing.
What does it mean to “do a thing”? There are (at least) two distinct ways we could mean this.
One is to fulfill some function. The tongue functionally does multiple things: it serves a role, minimally, in eating, and in talking.
But mechanically the tongue does one thing (and does it well). It articulates itself into various positions inside the mouth and throat.
This is where these two ideas come together without contradiction. Mechanically, each component should do one thing. When this mechanical capability is put into different contexts, it can achieve many different functions.
We might say that functional properties of things are contextually inherited, whereas mechanical properties are properly internal to the component. It’s a matter of scope of analysis: for mechanical properties we only need to look at the component, for functional properties we must look at how the component relates to its surround.
Composition of components means that each component is contextualized by other components with their own mechanical properties, while each component is a part of the other components’ context which give them their functional properties.
Do one thing, and do it well, so that you may do many things, so you may serve many purposes.
This relates to your previous article about sources of variety and importing vs. generating locally. I have to import (buy) a tools because I don't have the ability to generate them locally. Each one of those tools generally does one thing very well, but I can combine the output of the different tools in new combinations and even use them to create new tools for repetitive tasks. There might be a jig I could buy that already does what I need to do, but it will never be as good as the jig I create using my existing tools.
I've been using UNIX since the early 90s and that is the way the tools on UNIX work. I have to admit as well that I have never made the connection to other settings and processes outside of computing.