These devices will be of various nature: tools, thoughts, anecdotes, excercises, prompts, secrets, ... They will offer entry points to articulate _software documentation_ as a form of care.
Some elements of the list will relate to the materiality and surfaces where documentation is hosted, while others will be more entangled with the actors involved in the process.
To work within the constraints of a structure such as the list will help to think through the complexity of the topic. This complexity will hopefully be preserved and encoded in the relations between different items.
_Software documentation_ is not just a list of technical procedures, but also a matter of providing context and orientate code in the world. In the same way, the list is meant to be a texture where to weave together multiple voices and diverse registry, in order to re-enchant the making of software.
> "A list doesn't have to impose a single mode of ordering on what is included in it. Items in the list aren't necessarily responses to the same questions but may hang together in other ways... a list differs from a classification in that it recognizes its incopleteness. It doesn't even need to seek completeness. If someone comes along with something to add to the list, something that emerges as important, this may indeed be added to it." _[John Law and Annemarie Mol, Complexities: Social Studies of Knowledge Practices]_
### Why do you want to make it?
This project grows out of the frustration of finding myself often trying to deal with bad documented pieces of software. While for sure there is some thrill in understanding how to stitch together those codes, the lack of documentation poses a great hindrance for the participation of diverse knowledges in the making of software.
At the same time, this very lack of documentation could be used as a starting point.
Documentation is a space that interfaces between the code, the user, the developer, and the world. A space with potential to renegotiate and reclaim given margins and entry points. A chance to overwrite what is normalized, and let more voices participate in the discourse that is software.
Documentation is a way to produce narrations around software. To create a world for the code to inhabit, to give it affordances and stretch what is possible to do or to think with it. Documentation is a space for the political in the software. A surface that could host ideas in close contact with code, letting them entangle and shape each other.
I'm interested in the development of site-specific software. My artistic and design practice has always relied on the development of custom software to facilitate agency-on and comprehension-of complex systems. The tools themselves were never the main focus though, but rather just instruments to activate and be activated within particular contexts. Tools tailored to specific moments and then forgotten.
During the first year at XPUB the approach started to change. Working together with my classmates let me realize the importance of sharing tools. To develop not just for yourself, but also for others. Code as common. How important it is to create a space for these tools to circulate, and how important are the narrations we build around these instruments. In this sense software development could be seen as a form of publishing.
After the work in the past Special Issues, I'm trying to shift from compulsive development to susteinable development. Sustainable in relation to the context and the other actors involved in the process. This requires to learn how to balance between different priorities, to understand when to develop something from scratch and when to participate into already existing discourses. It means to learn how to balance between accessibility, susteinability and flexibility.
To make software means not only to write code, but also to take a stance regarding this trends.
Coding is not just production of software, but also production of knowledge. A dialogue between human and more-than-human actors. The guestlist of this conference of the bits is often compiled by chance: the choice of a particular programming language, the coding style, the development environment and ecosystem, the infrastructure that runs the code, and so on, are the result of specific contingencies.
These contingencies are situated in precise contexts, and these contexts are different one from another. Programming is not just sharing code, but sharing context. Programming means to provide a point of view and a perspective to look at the world, before attempting to get some grip onto it with a script. That's the reason why even if source code, even when obfuscated, speaks for itself, it cannot always cast light around its surroundings.
To make place for code turns to be a necessary act of care in the process of sharing knowledge. This does not mean to constrain the usage of some piece of software, or provide opinionated solutions or tutorials, but rather letting others know where does this code come from, and where it would like to go.
- Hayles, N K (2005) My Mother Was a Computer: Digital Subjects and Literary Texts, University of Chicago Press
- Sterling, B (2005) Shaping Things, MIT Press
- Mackenzie, A (2006) Cutting Code; Software and Sociality, International Academic Publisher
- Suchman, L A (1987) Plans and Situated Actions: The Problem of Human-Machine Communication, Cambridge University Press
Balibar, É (2020) On Universals: Constructing and Deconstructing Community, Fordham University Press
- Cantwell Smith, B (1996) On the Origin of Objects, Bradfor Book
- Knuth, D E (1973) The Art of Computer Programming, Addison-Wesley
- Knuth, D E (1992) Literate Programming, Center for the Study of Language and Information
- Brodie, L (1984) Thinking Forth, Punchy Publising
- Wendy Hui Kyong Chun, "On Software, or the Persistence of Visual Knowledge" (2005) Grey Room. 18
- Lethbridge, Chantelle & Sim, Susan & Singer, Janice. (1999). Software Anthropology: Performing Field Studies in Software Companies.
- Crowston, Kevin and Howison, James, "The Social Structure of Open Source Software Development Teams" (2003). School of Information Studies - Faculty Scholarship. 123.
- Shirky, C (2004) [Situated Software](https://www.gwern.net/docs/technology/2004-03-30-shirky-situatedsoftware.html)
