Today Iā€™m starting a new job working as a software developer at Stanford University as part of their Digital Library Systems and Services team. For at least the last decade DLSS has been building standards, technology and practices for digital library, archives and repository systemsā€“not only for Stanford, but for the wider open source and GLAM communities. Iā€™m really excited to have the opportunity to join their infrastructure team, and to work with some new and familiar faces, on maintaining and further developing their systems and services.

The maintenance angle is something that specifically drew me to this job. DLSSā€™ prolific output and impact is the result of many skilled people working together for a sustained period of time. The more software that is written and deployed, the more challenging maintenance work can become. Knowing when to refactor, replace or retire applications and services can be extremely tricky, especially when some of those applications are interdependent, and/or are open source and used in other contexts. The longer Iā€™ve worked as a software developer the more interesting these questions of maintenance of existing systems, as opposed to greenfield development, have become.

When I joined MITH back in 2014 they had an extensive back catalog of projects and applications that needed to be cared for. I helped migrate many of these to AWS where they became more legible (resource utilization, cost) compared to the server that they had accreted on at the University of Maryland. Over the course of my stay there I gradually also migrated these ā€œsitesā€ from dynamic database backed applications to static sites, sometimes with degraded functionality that was negotiated with their original creators. Upgrading these applications was increasingly untenable, and they often posed security problems. At the end of the day many of these projects remain online as a record of research activity that MITH was engaged in. It feels good to be leaving MITH having helped them manage this transition, which I think also created some breathing room for embarking on new projects.

As part of my PhD research I focused on how maintenance work and archival appraisal fit together. I think itā€™s useful to see decisions about what records to keep and which ones to discard as acts of maintenance and repair, because it highlights how these efforts are more than acts of preservationā€“they are acts of transformation. Sites of maintenance and repair are very often places where values get expressed. What things actually get attention over others is not simply a question of managing priorities, but is a real material expression of individual, organizational and cultural values. This was especially true when looking at web archiving practices, where born digital records and the systems that are used to manage (crawl, index, replay) them are intertwined and interdependent (Hedstrom, 2002).

Another dimension that my research explored was how maintenance work can sometimes operate under the radar as a conservative force, preserving established interests, sustaining the status quo, and serving the purposes of vested power, instead of allowing for needed and necessary change. One way of working against this tendency is to understand maintenance and repair work not only as expressions of value, but as a pivot point for transformative (not only incremental) change (Jackson, 2014 ; A. Russell & Vinsel, 2016 ; A. L. Russell & Vinsel, 2018) as well as a practice of care (Maintainers et al., 2019).

Hopefully this orientation wonā€™t make my work more confusing, because there will be a lot to understand. Maybe too much. Iā€™m actually excited about this new role at Stanford because it shifts my footing back to working as a software developer on a team of software developers. For the last eight years Iā€™ve worked as a software developer, but this has largely been solo or paired work, and mostly inflected towards research. The aspects of research that sent me back to school, and that have always interested me the most were ones that engaged with practice (rather than ideation and theory) so Iā€™m very grateful for the opportunity to re-engage with practice after some time away. Look for some of my notes here to pop up here as I get into it.

References

Hedstrom, M. (2002). Archives, memory, and interfaces with the past. Archival Science, 2(1-2), 21ā€“43.
Jackson, S. J. (2014). Rethinking repair. In P. Boczkowski & K. Foot (Eds.), Media technologies: Essays on communication, materiality and society (pp. 221ā€“239). MIT Press. Retrieved from http://sjackson.infosci.cornell.edu/RethinkingRepairPROOFS(reduced)Aug2013.pdf
Maintainers, T. I., Olson, D., Meyerson, J., Parsons, M. A., Castro, J., Lassere, M., ā€¦ Acker, A. (2019). Information Maintenance as a Practice of Care. https://doi.org/10.5281/zenodo.3251131
Russell, A. L., & Vinsel, L. (2018). After innovation, turn to maintenance. Technology and Culture, 59(1).
Russell, A., & Vinsel, L. (2016). Hail the maintainers. Retrieved from https://aeon.co/essays/innovation-is-overvalued-maintenance-often-matters-more