@ -56,39 +56,38 @@ The simulation is structured as a series of stages:
1. Requirements
1. Requirements
Where to decide and define the elements involved in the simulation.
Where to decide and define the elements involved in the simulation.
2. Setup
2. Setup
Where we join these actors together in small combinations.
Where we join these actors together in small combinations.
These will be the starting worlds of the simulation.
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.
3. 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 more iterations, the deeper the simulation becomes.
```
0 do loop
1 for each world
2 for each participant
3 ask for updates
```
```
The structure of the simulation resembles a nested loop: for each world visit each participant, and ask for updates.
0 do loop
Actually, we can save resources simulating just the combinations we want to explore, and not all the worlds of the initial dataset.
1 for each world
The more iterations, the deeper the simulation gets.
2 for each participant
3 ask for updates
```
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.
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.
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
4. Insert documentation element
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?
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?
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?
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?
