@ -21,7 +21,7 @@ Research how writing software documentation changes depending on the context and
Experiment with software documentation as a generative device to keep thinking through code from multiple and different perspectives.
Explore software documentation as iterative process, that grows and shrinks through versioning, and embrances branching to adapt to other environments.
Explore software documentation as iterative process, a format that grows and shrinks through versioning, and embrances branching to adapt to other 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.
@ -37,9 +37,9 @@ Develop tools to facilitate rich software documentation. To assist and stimulate
Define a domain of research. Where does software documentation begin and where does it end? What about tutorial, guideline, and demo? How porous is this surface?
Start to set some coordinates 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.
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 some documentation reactivate old prototypes, or cast different light on them?
Expand the research to tap into projects outside XPUB, such as freelance works and [artistic research](../ooc-summer-session/). Are there ways to make the documentation process more sustainable? Which strategies to overcome a low resources environment?
Expand the research to tap into projects outside XPUB, such as freelance works and [artistic research](../ooc-summer-session/). Are there ways to make the documentation process more sustainable? Which 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 is it 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?
@ -63,44 +63,47 @@ Try to infiltrate the industry of software development through their documentati
**October**
<!-- Define practically a method for the methodology: think about protocols and possible formats for graduation project outcome.
Get in touch with different communities for case study 2 and 3. -->
Define a domain of research. Do not decide on it's granularity.
Define the premises where which to ground the project by revisiting first year projects. Draw a political compass of software as care.
Think about a glossary and possible formats to test some concept in a small scale, such as the first public moment at Leeszal or the freelance works for Non-Linear and CLI.
Think about a glossary and possible formats to test some concept in a small scale, such as the first public moment at Leeszal or the freelance works.
Experiment while writing the documentation for the [Padliography](https://hub.xpub.nl/soupboat/padliography/) and the [Workbook](https://hub.xpub.nl/soupboat/workbook/).
**November**
<!-- Work on OOC, preparing for December performance at NaO Festival, Milan. -->
<!-- Develop context and prep-works for case study 2 and 3: plan timetable. -->
Work on OOC for December performance at NaO Festival, Milan. What does it mean to document a bespoke tool that I'm developing just for this project? Experiment with the documentation for the interactive patch of OOC.
Get in touch with key figures to interview for research.
Gather material to have an historical overview of software documentation.
**December**
OOC performance and follow-up about findings for the methodology.
OOC performance in Milan.
Follow-up about the different documentation processes.
**January**
Start working on case study 2.
Start working on case study 3.
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.
**February**
Work on one case study.
Update protocols and possible formats for graduation project outcome.
Read read read and write write write.
Interview and case studies from different communities?
Experiment with the idea of versioning, branching, collaborative writing.
**March**
Work on the other case study.
Update protocols and possible formats for graduation project outcome.
Induce dreams about the final outcome with a follow-up on the thesis research.
Research and prototype possible formats for graduation project outcome.
**April**
Follow-up about findings for the methodology.
Production for methodology outcome.
Production!
Think about graduation exhibition and collective pubblication.
**May**
Production for methodology outcome.
Production for graduation exhibition.
Production!
Think about graduation exhibition and collective pubblication.
**June**
Graduation exhibition.
@ -111,6 +114,21 @@ Siesta
### Why do you want to make it?
Software comes from a really specific occidental cultural tradition.
Software tends to priviledge masculine, binary, exploitative and extractive practices.
Software is shrouded in technical obscurity.
Software comes invisible, transparent, neutral.
Software models the world in order to control it.
To make software means not only to write code, but also to take a stance regarding this trends.
To make software means not only to write code, but also to create a context and community around it.
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 undo 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,
@ -120,81 +138,68 @@ when you're using a tool you can learn the world throught the use of it, the dif
<!-- This is a list of current trends that the software industry enforces and naturalize.
Software comes from a really specific occidental cultural tradition.
Software tends to priviledge masculine, binary, exploitative and extractive practices.
Software is shrouded in technical obscurity.
Software comes invisible, transparent, neutral.
Software models the world in order to control it.
To make software means not only to write code, but also to take a stance regarding this trends.
With this project the intention is to situate my practice within ethical yet sustainable boundaries. -->
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.
As a piece of code would write: I am documented, therefore I am. 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.
<!-- 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. -->
### Who can help you and how?
I would like to interview some artists with programming-related practices to get some glimpse of their workflows.
I'm thinking for example to Nathan Sinigalia, Ian Cheng, Nicolas Maigret.
I want to ask to Ariella Vidach A.i.E.P. how working with technology changed in the past 30 years.
I'm interested in the workflow of radical studios such as Open Source Publishing but also more commercial ones like Forensic Architecture and Studio Moniker.
For sure it would be interesting to get in touch with someone mantaining open source projects such as Paged.js, P5Js, vvvv, or more unconventional ones.
It would be interesting to get in touch with someone mantaining open source projects such as Paged.js, P5Js, vvvv.
Some interesting things could emerge from field research directly in git repositories, issues and wikis.
The practical aspect depends on the second and third case studies. There are some communities I would like to work with: Pietre Parlanti is a non-profit association that works with the recovery of old routes and cultural heritage in Liguria, Italy. I'm already in touch with them for [Frana Futura](../frana-futura/), the documentary I'm working on with Sofia, Elena and Micalis.
### Relation to previous practice
> 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.
### Relation to a larger context
> 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.
### References/bibliography
- software studies - ed. matthew fuller
- close to the machine - ellen ulman
- ways of being - james bridle
- new dark age - james bridle
- cuttling code - software and society - adrian mackenzie
- gay robot noises - comfy software
- kent beck - wiki.c2.com
- extreme software & SCRUM
- simon yuill
- [The Social Structure of Open Source Software Development TeamsTeams](https://surface.syr.edu/cgi/viewcontent.cgi?article=1081&context=istpub)(2003)
- 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)
