oh no another client project what do i do
How can philosophy help us describe client and project needs?
You’re reading DisAssemble, a biweekly philosophy of tech newsletter aimed at those interested in creating better digital products.
Whenever I start a project with a client I feel a creeping anxiety.
How can I possibly understand the domain that the client works in? Why would my presence, that of an ignorant interloper, be of any value?
I was always jealous of colleagues, who, within seconds, could immediately understand everything about a client. It's like they could sense the rhythms and manners of the client’s speech, mirroring and refining them.
But no - it was more than that - they quickly understood the things that mattered to the client. Not quite the challenges, not quite their needs - but the implicitly delineated concepts that existed as both intangible and tangible ‘things’ of discussion.
I'm working now on a project now that is intended to help deliver information from a diagnostic device to an app, then to a dashboard. Wrapping my head around exactly how we are supposed to help with this project is tremendously difficult.
We are supposed to help move this project forward by identifying ‘use cases’ for a diagnostic device involved in this process. But what does ‘use case’ mean?
I mean, I know what a use case is, definitionally, but what is it terms of the considerations of this project? How existing technology works? How it might work? Where it might work? The tasks that users need to undertake, agnostic of the technology? The setting involving particular tasks?
Wrapping your head around what you might call the ‘area of consideration’ is enormously challenging. One key challenge is that we don’t have any good words to describe what we’re talking about here. ‘Area of consideration’ isn’t quite right because what we are speaking of is more than an ‘area’, it's a sort of pseudo-concept/object, with sprinkles of actions, words, ideas, goals and things.
And ‘thing’ - what about that? Thing is a word that comes close to what we are talking about. Thing originates from Proto-Germanic, roughly meaning ‘an appointed gathering to discuss an area of concern’. Thing holds much of this meaning to this day. Think of the Italian mafia, the ‘cosa nostra’, which is translated as ‘our thing’. It’s a thing of concern, consisting of people, behaviours, expectations and places.
But generally, the label ‘thing’ is too associated with purely material conditions.
A word that is a rough descendant of ‘thing’, ‘assembly’, seems to fit better, as it does not have such strong connotations towards the purely tangible.
In particular, the philosophers’ Deleuze and Guattari's variation ‘assemblage’ seems a suitable way to describe these sorts of areas of concern (it also motivated the name of this newsletter). Think of a group of things that are fluid and exchangeable, but together make up something new, and this new thing has its own qualities. An assemblage can be language. It can be a city. Or an online marketplace. Even a set of beliefs.
But it can relate to more specific areas - such as those within our jobs. ‘Use cases’, for instance.
Or, as another example, let’s look to the job of web developer.
Web developers need to understand programming languages, yes, but there are other ‘things’ (assemblages) they need to understand. The DOM (Document Object Model) is a key example of an assemblage.
Here's what Mozilla says about DOMs:
The DOM represents a document with a logical tree. Each branch of the tree ends in a node, and each node contains objects. DOM methods allow programmatic access to the tree. With them, you can change the document's structure, style, or content.
The DOM is made of multiple nodes and objects and structures the content of a website (I think this is right - I’m no web dev). But a DOM is also an approach to web development.
So in this way, a DOM is a series of ‘objects’, or subsets of categories of ‘objects’, yet it isn’t just an object. A DOM is its own thing.
At the same time, it is part of a concept - it’s part of web development methodology, but it isn’t just this concept. Again, a DOM is its own thing.
A DOM exists as an assemblage - as a thing with its own qualities. It can be discussed, moved, and even direct standards of behaviour (there’s best practices for DOM). But it also is made of individual elements (nodes etc.) and is part of the approach to web development.
So assemblages are very difficult to parametrise as they can include the intangible - such as beliefs and concepts - and objects - such as lines of code, people or places. This ambiguity, however, is where their power lies - they don’t fit nicely into existing categories.
Let’s turn to some examples.
Love and Marxism are concepts. A text message to your significant other and a Soviet ruble are objects. But let’s consider online dating culture in the 2010’s, or communism in the Soviet Union. These would be assemblages as they contain objects (text messages to significant others and rubles, respectively) and concepts (love and Marxism, respectively), but they also have qualities in and of themselves.
So The Assemblage, as described here, sits somewhere between The Concept and The Object, but also contain concepts and objects.
My client’s ‘use case’ is a good example of this. It seems to include a series of diagnostic devices, the behaviour of the people using them, and their needs and challenges. I think. This is what I need to investigate…
It can be really difficult to pin down what an assemblage is, or does. And assemblages are subjectively interpreted as well - they can mean different things to different people.
One thing is clear, however; these assemblages need to be treated with a respect that preserves their qualities. Too often, we take the wrong perspective and cannot see these qualities.
This can be illustrated through a quote from the Iron Lady.
Famously, Margaret Thatcher said ‘There is no society’. By this she meant by that there are individuals and families, but that society itself was a false notion. People are responsible for themselves, she argued, as a society was in actuality nothing more than a large group of individuals. Rugged individualists - libertarians and perhaps anarchists - would agree.
But this doesn’t explain codes of conduct in a society, culture, or anything that exists as an orienting, dictating, shaping quality of a society.
This reductionism is common within the scientific worldview as well. Scientists often see the world as discrete elements, with each thing being fully explainable by the workings of smaller parts (atoms, DNA, etc.).
But shifting our perspective ‘higher’ is problematic as well.
In the novel Satin Island by Tom Mccarthy, a ‘cultural anthropologist’ known only as U. is aiming to write a 'Great Report' for the company he works for. U.'s boss says it will be "the First and Last Word on our age". What exactly is this report? What will it do? It’s never made precisely clear.
U. attempts to connect random events in the world - a parachutists death, an oil spill, his friend's cancer - to have meaning in this report. Everything has meaning because it is part of a pattern. U. aims to look at all things in a way that maps on to a larger, meaningful whole.
But U.'s report never materialises. There is no grand narrative that meshes the individual components of U.’s life in any meaningful way. For U., each object was just part of a larger pattern, it had no intrinsic meaning other than being a part of a fantastical greater whole.
Literary criticism and philosophical speculation (including this newsletter) could be accused of succumbing to the sort of crazy wall, conspiratorial, pattern finding ailment that afflicted U.
The philosopher Graham Harman provides us with a fantastic vocabulary to describe these perspectives as part of his theory of Object-Oriented Ontology. I won’t go into his theory here, but I’ll draw out two of his concepts. He calls what Thatcher did 'undermining' and what U. did 'overmining'.
Thatcher was undermining society to its component parts.
U. was overmining individual events in his life into mere pieces of a larger whole.
Thatcher and U. weren’t treating a thing for what it was, they were treating it as of parts or a part of, respectively.
So in addition to sitting between the concept and the object, assemblages sit somewhere between the overmined and the undermined.
Note that the above diagram is just from the perspective of an assemblage in question. Assemblages can be part of other assemblages. You could consider HTML an assemblage, but also an overmined aspect of a DOM (because a DOM is just a part of it).
Also note that assemblages exist as abstract versions of themselves and instantiated versions of themselves. Think of the relationship between the idea of a thing and a specific thing. A brown bear and the brown bear, a Macbook Air and the Macbook Air. So too can you have the abstract DOM, then you have an instantiated DOM.
Here’s how ‘a DOM’ might look on the above graph.
The assemblage of a DOM sits in the centre. Then, there’s a variety of another aspects sitting on a spectrum of concept/object and overmined/undermined in relation to a DOM.
A <body> tag is an undermined part of a DOM, but the <body> tag has that quality and is also more of an object.
Technical infrastructure is much more of a grounded object than a DOM, but a DOM is also only a small part of it, so such infrastructure is both more an object than a DOM, but also contains a lot more than just the DOM.
Let’s look at something that is perhaps more work-related. My ambiguous use case.
We can begin to see important things, like the UX of any device used and client needs, as being concepts that a use case is a part of, while user needs and behaviours would be conceptual considerations in a use case.
Meanwhile, how the project is rolling out and specific budgets involved are more tangible objects that a use case would be a part of, while settings and technologies involved in use cases are tangible parts of use cases.
Note that this diagram doesn’t have to be perfect - but it’s a useful way to represent and discuss the character of an assemblage in question.
And indeed, with all of these elements, it’s easy to forget that a use case has its own qualities. It can shape our actions. For example, the use case can shape the goals of a project, and guide how we collect information.
It’s easy to see this by looking at another example - Thatcher’s supposed non-existent 1980’s British society.
We can see some of the different concepts and objects (and possible assemblages) involved. But none of them are 1980s British society, though they all interact with it in different ways. 1980’s British society had a particular character, and it shaped how people lived through it and how we discuss it.
But the question remains - how do you understand an assemblage on its own terms, without overmining or undermining? How can you fathom the assemblage, and its qualities in a way that allows you to appreciate it for what it does?
That’s a story for next newsletter!
Hopefully I’ll have figured out my client’s ‘use cases’ by then. Wish me luck.