Explore software documentation as iterative process, as a format that grows and shrinks through versioning and embrances branching to adapt to specific environments.
Develop tools to facilitate rich software documentation. To assist and stimulate the writing process with prompts and gently reminders that software documentation is a form of care.
<!-- Research how writing software changes depending on the context and actors involved. Bring the specificities of different case studies: coding for oneself, coding for others, coding together with others. How can different nuances of these three settings inform and resonate one with the others? -->
<!-- Elaborate on the idea of care. Care for who and in which way? Care for what and from which perspective? Lay out these different subjects and annotate the ways they interact, reinforce, or dampen each other. Where and how to orientate software development in this chart? -->
<!-- Try to make a public for this practice in subtle ways: how to offer entry points for (or escape routes from) the stereotypical western white male macho programmer? Is it possible to infiltrate the ultra efficient and violent industry of software development, seasoning its own tools? How to intercept some established practices and branch from them? How to publish outside our safe XPUB bubble? -->
Define a domain of research. Where does software documentation begin and where does it end? What about tutorials, guidelines, and demos? How porous or tentacular is this surface?
Set some references by looking back at the works made last year and read them through the axis of code and care. Or some other system of coordinates that suits better. Could the process of writing documentation reactivate old prototypes, or cast different light onto them?
Expand the research to tap into ongoing projects outside XPUB, such as freelance works and [parallel research](../ooc-summer-session/). Are there ways to make the documentation process more sustainable? Are there strategies to overcome a low-resources environment? What are the relations between documentation and the communities around a software?
Question the nature of the documentation: what does it take for granted? For what kind of public it is produced, and what kind of public does it produce? How does it normalize the context around the software? What are its politics of access? How does it create entry points and how does it gatekeep?
Try to infiltrate the industry of software development through documentation. Attempt to expose their public to these questions in subtle ways. Offer entry points and escape routes from the universal solution proposed by big corporates.
<!-- Writing software and taking care are meant to be moments of research and curation of contents in the form of resources, experiences and approaches. Starting from the assumption that there is no universal solution for writing software, and that coding is always site specific, this research could set some coordinates by looking back at the works made last year and analyze them through the lenses of code and care. -->
<!-- Along with this initial reflection on the first year, the plan is to focus on three case-studies of different nature. One in which I develop for myself, one in which I develop for someone else, and one in which I develop together with some others. These projects will not start from scratch, I -->
<!-- Developing for myself could happen in the context of [Object Oriented Choreography](../ooc-summer-session/), a long-term contemporary dance research with VR and networked media. The team I'm working with for this project is small, and I'm the one in charge of the art direction and interaction design. -->
<!-- Developing for someone else refers to commisioned and freelance work. It could be a way to bring not only the advantages, but also the perspective and cultural dynamics of F/LOSS into commercial practices. My freelance work usually consists in developing websites or interactive application to be used in performative context. It could be a way to orientate specific commision to the development of tools of general use. -->
<!-- Developing togheter with others it's a way to renegotiate priorities when developing software. How do we value and balance between accessibility, flexibility and sustenaibility? This could happen either collaborating with someone from XPUB (think for example to the [workbook](../workbook/) with supi, the ilizarov projects with gr, etc ) or intercepting some external realities' need to craft together some piece of site-specific software. -->
Experiment writing the documentation for the [Padliography](https://hub.xpub.nl/soupboat/padliography/) and the [Workbook](https://hub.xpub.nl/soupboat/workbook/).
Work on OOC for December performance at NaO Festival, Milan. What does it mean to document a bespoke tool developed just for this project? Experiment with the documentation for the interactive patch of OOC.
Gather material to have a critical overview around software documentation.
Field research of the current state of software documentation. Explore different fields: big projects, small projects, corporate documentation and solo developers. Explore different languages and reflect on how they features are reflected in the documentation.
Experiment continuing writing the documentation for different prototypes. How does this process of writing documentation inform the process of writing the thesis?
Experiment with the idea of versioning, branching, collaborative writing.
Documentation is a space that interfaces the different actors around software. Software documentation is a space with potential to renegotiate and reclaim given margins and entry points. It is a chance to overwrite what is normalized, and let different knowledges and voices participate in the discourse around software.
Documenting software it's a complex practice. Documenting software is a process of translation. Writing documentation it's more difficult than writing software itself. It requires a lot of time and energy, and it involves many different skills: writing, coding, knowing how to share and at which intensity. It's a collaborative practice that could open to different voices.
As a piece of code would write: I am documented, therefore I am.
developement is really specific technical community (white cis male eheehhe)
a lot of violence, status quo, reinforced in the industr, competition,
control, frame the world in a form that you can control and act on from a really occidental point of view, colonialistic, extractive form
i would like to research on the question: can we do it in another way? giving back something and not only take
when you're using a tool you can learn the world throught the use of it, the difference is: can i use the scissors to cut a piece of paper and make a notebook or kill someone? -->
<!-- And viceversa. Undocumented software is invisible, but for the eyes of their own developers. And eventually, it begins to fade as soon as the developer looks away. -->
> The ordinary professional programmer addresses himself to the problem to be solved, whereas the compulsive programmer sees the problem mainly as an opportunity to interact with the computer. (Joseph Weizenbaum)
I'm into the development of site-specific software. Codes that inhabit and interact with a community. Coding as a form of care. Programming as a way to facilitate agency-on and comprehension-of complex systems. I'm trying to learn how to approach complexity as an environment. How a work can be complex without forcing the result being complicated. This usually happens when diverse actors participate in a process, when ideas and practices traverse through the software without being totally framed into it.
After the work in the past special issues, I'm trying to shift from developing compulsivly to developing in a meaningful way. Meaningful especially in relation to the environment and the other people involved in the process. This means 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.
> Code is always addressed to someone. [...] We do not write code for our computers, but rather we write it for humans to read and use. [Jesse Li (2020)](https://blog.jse.li/posts/software/)
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.
> If software illuminates an unknown, it does so through an unknowable (software) ([Wendy Hui Kyong Chun](http://computationalculture.net/software-studies-revisited/), 2022)
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.
> “Our machines should be non-binary, decentralized and unknowing.” (James Bridle. “Ways of Being.”)
Documentation is a way to produce narrations around software. To create a world for a software 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 of software. It's a surface that could host ideas in close contact with codes, letting them entangle and shape each other.
- Fuller, M ed. (2008) Software Studies: A Lexicon, MIT Press
- Ullman, E (2013) Close to the machine: Technophilia and its Discontents, Pushkin Press
- Bridle, J (2022) Ways of Being: Beyond Human Intelligence, Farrar, Straus and Giroux
- Bridle, J (2018) New Dark Age: Technology and the End of the Future, Verso
- Bratton, B H (2016) The Stack: On Software and Sovereignty, MIT Press
And then a list of possible references
- 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
- Law, J ed. and Mol, A ed. (2002) Complexities: Social Studies of Knowledge Practices, Duke University Press Books
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)
