We need to un-flatten computation
Cause encoding human relationships in databases is a fraught process...
You’re reading DisAssemble, a triweekly philosophy of tech newsletter aimed at those interested in creating better digital products.
Bureaucracies curse me with a special kind of anxiety. A cold well of dread presses down inside my stomach whenever I have to deal with some byzantine telecom, or the government. Filling out paperwork gives me heart palpitations.
It’s not just me, I think. For most, bureaucracies are frustrating, impenetrable and most of all, forcefully categorical. You are in tax category A, or B, you are married, or unmarried, you are a citizen, you are an immigrant. Kafkaesque? Yes, intrinsically. But not merely because bureaucracies are byzantine, but also because they flatten.
Bureaucracies must reduce the mushy and open-ended into a quantified singular in order to process it. The administrator’s ledger needs a quantified category to put a person in. This linear, codified language of bureaucracy relies on the the same logic as computation (which it often works in collaboration with). And it often catalyses the same result:
“I’m sorry sir we can’t do anything about it - it’s what the computer says”.
Like bureaucracies, computers attempt to flatten - they squash the complexity of being down into a flat structure, based upon someone’s interpretation of what 'is'. Unfortunately this flattening then cascades out into the real world.
This is analogous to the thesis of Nick Sousanis’s (comic)book “Unflattening”, which argues that the primacy of linear writing over other more visual, dynamic forms of communication flatten the possibilities and potential of what we can describe.
Facebook is a good example of flattening, with their idea of ‘friend’.
On the platform, you can add ‘friends’. But the nuanced dynamic, quality and context of relationships are hardly encompassed by a single word - ‘friend’. In human relations we can discuss what a friendship is, describe it, but in human-computer relations, the complexities of a human relationship is flattened into the all encompassing ‘friend’.
This has implications: ‘friends’ are granted access on flat plane - they are treated to the same levels of exposure as all other ‘friends’; that is, everyone you know on Facebook. The same photos, the same content. Now, this is something that Facebook and its successors/competitors (such as Google+) wrestled with, with varying levels of ‘access’ used as a way to reflect the complexity of human relationships. Yet they all failed.
But problem isn’t just limited to the fact that the the complexities of dynamic human relations are compressed into a single word, it’s also that the context in which we use these words is absent. The context can define a word as much as the complexity.
The philosopher Hubert Dreyfus gives the example of someone asking another person, “Is there water in the fridge?” Depending on the context, this may have a variety of meanings. Two scientists could be discussing whether H20 molecules are present. A plumber could be asking where water is leaking. A couple could be discussing whether there is a jug of water in the fridge. We can’t know for sure unless we know the context. Importantly, the context helps commit us to action. We know to what the person refers, and can move forward. Language contextually has meaning and commits us to courses of action, even in misunderstanding. Dreyfus explains:
If the speaker says "Yes, there is water in the refrigerator" and the hearer can't find any, the speaker is committed to give an account.
This is true for the scientist, the person with the plumbing issues, or the couple.
In digital product development we can see how necessary context and complexity dissipates as the the idea turns into a product. Complex, contextual situations eventually gets reified in the database, codified and flattened. In other words, different situations, problems get narrowed into linear tasks, which get embodied in designs and then databases:
Within the database the language used is inherently not apropos - it no longer has the context and complexity that it does in the world of messy human relations.
Importantly, this language is still required to enable action. And this is a problem because databases structure much of the world; any type of system or bureaucracy uses a database.
No matter their good will about how to enable ‘friending’, Facebook has to flatten the context and the complexity of human relationshiops from broad dynamics about socialising, and the different types and contexts of relationships into a single item: a “Facebook Friend”.
But, here’s the thing: this word, within Facebook’s ontology, still commits us to action. As Dreyfus says, this is what language does - we use language to coordinate action via mutual comprehension. A key difference is that we can’t ‘discuss’ it with the computer, and come to a mutual understanding; it is ossified in the language the computer knows (we can only communicate by ‘adding’ or ‘removing’ friends). And to this extent, the computer is incommunicado, unless you are a programmer.
A worrying question arises: encoded human relationships are ‘flattened’ and aren’t subject to interrogation and fluidity - sure - but does this data structure come to flatten the human situation ? Does one become a ‘friend’ - that is, shaped into having a certain relationship with another person - because they are codified as such within the data? Does the human follow the computer?
I would argue that this is the case - relationships become flattened into specific dynamics. Facebook affords particular styles and modes of communication - specific types of praise, or one-liners take hold, embodying particular relationships. This is true for other types of tools like LinkedIn, Slack, or even Project Management tools such as Jira. Context of relationship becomes specific to the context of the medium, and complexity of such relationships is reduced to that which the medium affords. People begin speaking and behaving in ways that align to the flattened structures within the database that purportedly represent their relationship because it enables action, albeit in this more limited way.
It’s a worrying concept, but perhaps it is one that is not new.
The origins of writing appear during the start of the pottery phase of the Neolithic, when clay tokens were used to record specific amounts of livestock or commodities. These tokens were initially impressed on the surface of round clay envelopes and then stored in them.
Did the types of ownership of commodities and animals exist prior to them being flattened into the representations of ownership, or did it enable such ownership? In other words, could we have had more dynamic forms of ownership, of relationships, had they not been codified in this way?
Or even more broadly, is the way that we have come to exist based upon relationships that have been codified - very literally - in stone? The late David Graeber and David Wengrow would agree, I would think, and say that these very fundamental precepts of civilisation are contingent, not destined.
But I digress. The point here is that modelling human relationships in formalised, cemented structures can be a dangerous exercise that results in shaping the relationships themselves. People can become what the cemented structure suggests, and in doing so lose out the dynamism of the human relationship, lose out on the creativity that comes from non-codified roles and relationships. In the least, structuring human relationshiops in databases is ineffective in terms of adhering to the fidelity what actually exists.
Because of all this, imposing models of humans relationships on humans that are codified and embodied in mediums often fail badly, or they create rules that people ignore.
Project management software, for example, generally doesn’t account for types of relationships exclusive to that organisation, the types of work people like doing, how people like to work, or the peculiarity of the work to the task. Therefore, people find workarounds, or they ignore rules that don’t suit them, or pay lip service to the software.
So - what can we do instead?
To quote Dreyfus again:
The most successful designs are not those that try to fully model the domain in which they operate, but those that are 'in alignment' with the fundamental structure of that domain, and that allow for modification and evolution to generate new structural coupling.
We can see inklings of this in many tools like Notion, Clover, Slite, Miro and any number of other ‘whiteboarding’ and collaborative tools taking the fore. They allow near constant modification of domains because they don’t specify relationships and hierarchies at the outset. They allow hierarchies and domains to exist, but the data is flexible and dynamic, not hard-coded in any back end - that is, they allow for new ‘structural couplings’. In other words, there is communication with the back-end - people can ‘discuss’ how and what information is encoded within the computer.
So: be wary of tools that codify - especially those that codify human relations. Work with those that adapt to the flexibility of what we are: messy, open-ended piles of complexity, reaching out to one another. We shouldn’t try to fit ourselves into anxiety-inducing, hardened bureaucracies. Nor should we ask that of others.