Ryan Singer posted this on twitter:
“Adding” and “integration” are different operations: Adding: Bolt working wholes together w/ no problem solving. Integration: Solve lots of problems to connect parts together into a working whole. Complex problem? Orthogonalize into integration problems that can then be added.
source
I had to read it a couple of times to get it … and I did. But when I did I also realized that it left a tension in me (that in retrospect was related to why I had to read it more than once). The tension originated from a dissonance between:
- The “adding” being the healthier operation.
- The description of adding as “bolting holes together” which feels to me oddly mechanistic and ill-suited and that
- The description of “Integration” does speak to a “working whole”
**points 2 & 3 originate from what I understand to be Ryan’s relationship to the work of Christopher Alexander … a relationship that evokes in me a sense of kinship.
Alexander speaks of growth inspired by the way nature does it – from the inside it. An embryo is a common example: there are never parts that are added or integrated. The single cell is whole and by splitting becomes more whole (larger with a more refined internal structure) … over and over again. With that in mind I reflected on Ryan’s discernment between “adding” and “integrating”.
I imagined the software as a kind of living blob:
… and as it lives and interacts with the world it inhabits, ultimately seeds appear – a seed represents a potential need (eg: JTBD) … at first they may go unnoticed … a slight itch or hiccup in the flow of operation:
When it is noticed … what gradually becomes noticed is that something is missing … a void:
When that void becomes valuable enough and it is shaped … it expands … and even though not a single line of code has been written, the software as a being has “grown” to become a space.
When work is invested into it, it starts to become inhabited … not a void since there is a kind of ideological integration already in place … but not yet functioning as a part of the whole:
As the development cycle nears completion and most tasks are over the hump of the hill-chart … the new part starts to blend in:
Until finally (especially as time passes) you can hardly separate it from the whole:
The adding is from the inside-out and integration is ALWAYS present:
- The initial itch / hiccup seed is naturally integrated (it is born from the existing living software).
- The void is integrated in the sense that someone has recognized it WITHIN the whole software.
- The space that it becomes means that someone has seen how it can be made to be a living part (=integrated) of the whole software.
- If it is inhabited well it means that more people (now creating design/code…) are seeing how it can be made to be a living part of the whole (=integrated).
- As the new piece of software is completed the integration matures from the domain of idea to the domain of matter (as much as software can be matter).
- And when it fits into the whole, the new software as a separate thing is practically forgotten = deep integration.
I imagine that this pattern repeats itself in different scales. On a larger (zoomed out) scale the software itself was born this way when it started as a specific need within a living domain in the world … and can be viewed as inhabiting the world in this way:
And on a smaller scale (zooming it) the making of the new part of software is itself a living process of smaller parts going through similar pathways of maturity from ideological integration to manifested integration.
In this way integration is a systemic attribute … a quality … not an activity that you do explicitly.