- and propose software documentation as an entry point
- to renegotiate the context around software
- Outline the structure of the simulation
---
This introduction is not a written as a text, but runs a simulation.
This introduction is not a written as a text, but runs a simulation.
Coding Contingencies (CC) is a procedural take on how different characters got to code.
Coding Contingencies (CC) is a procedural take on how different characters got to code.
@ -34,7 +24,7 @@ It's providing a point of view and a perspective to look at the world, before at
Using the simulation as a writing machine we can articulate these CC with some benefits:
Using the simulation as a writing machine we can articulate these CC with some benefits:
1. Suspension of judgment
- Suspension of judgment
Within the scope of the simulation it's not necessary to label good or bad choices.
Within the scope of the simulation it's not necessary to label good or bad choices.
_(That would have been the case for a machine learning writing device, for example)_
_(That would have been the case for a machine learning writing device, for example)_
@ -42,35 +32,31 @@ Using the simulation as a writing machine we can articulate these CC with some b
Due to the nature of the process, even the most absurd starting point it's a valid and powerful narrative device.
Due to the nature of the process, even the most absurd starting point it's a valid and powerful narrative device.
In this way it becomes easier to explore marginal cases, improbabilities, and non-conform situations.
In this way it becomes easier to explore marginal cases, improbabilities, and non-conform situations.
2. Discrete temporality
- Discrete temporality
A simulation does not happen all at once, instead it is a process that evolves through time.
A simulation does not happen all at once, instead it is a process that evolves through time.
This happens in both discrete steps and long-term iterations.
This happens in both discrete steps and long-term iterations.
Discrete steps can be further subdivided or grouped together, with the possibility of magnifying details, and the ability of zooming in and out a story.
Discrete steps can be further subdivided or grouped together, with the possibility of magnifying details, and the ability of zooming in and out a story.
Long-term iterations are a way to keep asking _what's next? what's next?_ to the machine. At every cycle, the simulation reaches out to each partecipant and asks for an update. In this way all the actors and relations develop in parallel.
Long-term iterations are a way to keep asking _what's next? what's next?_ to the machine. At every cycle, the simulation reaches out to each partecipant and asks for an update. In this way all the actors and relations develop in parallel.
3. Partiality
- Partiality
Partecipants entangle gradually, and do not come as a monolithic block.
Partecipants entangle gradually, and do not come as a monolithic block.
They can be imagined as lines: merging together and branching away, tying and loosening knots. (Ingold)
They can be imagined as lines: merging together and branching away, tying and loosening knots. (Ingold)
This leads to multi-facets and situated (Haraway) subjects, where not all the elements needs to interact with each other all the time. Their interfaces can be loose, they don't need to be one hundred percent compatible to come together.
This leads to multi-facets and situated (Haraway) subjects, where not all the elements needs to interact with each other all the time. Their interfaces can be loose, they don't need to be one hundred percent compatible to come together.
4. Orientation
- Orientation
Zooming in and out from the particular, we get a glimpse of a more gradual and diffuse process.
Zooming in and out from the particular, we get a glimpse of a more gradual and diffuse process.
A subtle sense of direction emerge from the initial randomness.
A subtle sense of direction emerge from the initial randomness.
By design, the simulation articulates software as a mean to orientate, as well as being oriented by, these trajectories.
By design, the simulation articulates software as a mean to orientate, as well as being oriented by, these trajectories.
How does certain programming languages facilitate certain ways of thinking, and totally block some others?
How does certain programming languages facilitate certain ways of thinking, and totally block some others?
This procedure helps us to think about software as cultural object. Something "deeply woven into contemporary life –economically, culturally, creatively, politically– in manners both obvious and nearly invisible." (Software Studies, 2009), and not just as technical tool existing in a vacuum.
The simulation is structured as a series of stages:
[structure of the simulation]
After this overview, the simulation follows a series of steps:
1. Requirements
1. Requirements
Where we decide and define the elements involved in the simulation.
Where to decide and define the elements involved in the simulation.
2. Setup
2. Setup
@ -79,26 +65,30 @@ These will be the starting worlds of the simulation.
To keep things simple, each world will be a closed ecosystem, and there won't be explicit interaction between different ones.
To keep things simple, each world will be a closed ecosystem, and there won't be explicit interaction between different ones.
2. Worlds simulation
3. Worlds simulation
At this point each world will be really dry and synthetic, defined just by some labels that state that an actor is a musician, the name of a programming language, etc.
At this point each world will be really dry and synthetic, defined just by some labels that state that an actor is a musician, the name of a programming language, etc.
The structure of the simulation resembles a nested loop: for each world visit each participant, and ask for updates. Actually, we can save resources simulating just the combinations we want to explore, and not all the worlds of the initial dataset.
The structure of the simulation resembles a nested loop: for each world visit each participant, and ask for updates. Actually, we can save resources simulating just the combinations we want to explore, and not all the worlds of the initial dataset.
The more a world is iterated, the more in depth its simulation becomes.
The more iterations, the deeper the simulation becomes.
```
```
loop through worlds
0 do loop
for each world
1 for each world
visit each participant
2 for each participant
ask for update
3 ask for updates
```
```
3. Insert documentation element
Being a writing machine more than a piece of software, the process could be thought as a slow simulation. One that benefits the understanding of such a device and the quality of the different stages, instead of the quantity of iterations and generated data. A way to witness code and non-code entities (Mackenzie, 2006) coming together and shaping each other.
This procedure helps us to think about software as cultural object. Something "deeply woven into contemporary life –economically, culturally, creatively, politically– in manners both obvious and nearly invisible." (Software Studies, 2009), and not just as technical tool existing in a vacuum.
4. Insert documentation element
Throughout some iterations, the worlds will develop network of relations between actors.
Through some iterations, each world will grow a network of actors to play with. Once reached a sufficient mature state, we will introduce a new element: documentation. Throwing a pebble in the puddle to watch how it will ripple through. Which other elements will relate with it, and which one will not? Which transformation it will trigger in the dynamics of access, of power, and representation that are sprouting around software in each simulation?
[software documentation as entry point]
These emerging issues will articulate the main questions of this research: could software documentation be a surface to situate code in the world? Could it be a device to foster entry points for a more diverse participation? Could it be a way to orientate technologies with our set of values?
