While tooling around with some prototype spaces for “Project Lunfardo” (still a provisional name, I’m sure!) I was thinking about some of the unspoken or under-acknowledged tasks that must exist in the realm of DH scholarly software. I see a lot of discussion about the various roles like project management, design, development, outreach, etc., but references to things like maintenance and deployment tend to be more oblique. This was a topic I was playing with yesterday over on BlueSky. Today I’m connecting it more explicitly to care work, which our society tends to feminize and therefore devalue. We need only look at the twin mantras of “move fast and break things” (Facebook’s previous motto) and “it is better to ask forgiveness than permission” (a particular kind of misquote of a popular saying later attributed to Admiral Grace Hopper) to understand how acting over caring functions.

Personally, I’ve found a good deal of satisfaction in improving a piece of software and keeping it running. And that sort of care is necessary even if no actual functionality changes. Software is subject to entropy just like anything else, so it’s vital to keep its dependencies up to date, which will occasionally require code changes as deprecations creep in. This isn’t a post about good software practices, though it certainly could be. Instead, it’s a bit of a meditation on how/why to use the power of institutions to keep the lights on. I assume that when we make something that is supposed to serve a scholarly purpose, we want it to last beyond peer review. Perhaps it’s not always necessary, but I’m guessing we don’t undertake a DH project with the idea that the software will go offline and become more internet ephemera. That said, we also do well to remember that software has lifecycles, so there’s a balance here.

Making it available online in the first place is also a job that often ends up being thrown over the proverbial wall. I came to software via systems administration, having labored for years under that sort of “well, it’s someone else’s job to figure out how to deploy it” mentality, where developers would make something someone else would deploy it and keep it running. That someone else was me. A result is that I keep both the development and deployment contexts close together, because I don’t think you can really separate them.

At the very least, you need several things to put something online and keep it there. You need a domain name, an SSL certificate, and a place to host the code and the database. The smaller the system and the less traffic it’s intended to serve, the lower the overall requirements. Most systems will need to scale, however, and some will require the ability to send email (to register users, send password resets, and otherwise generate useful notifications). And finally, keeping them up to date is necessary to keep them online. These additional constraints benefit from institutional support, even though they can be supported by an individual or small team depending on their complexity.

NB: On the topic of “ask forgiveness vs ask permission”, the actual saying was that it is easier to ask forgiveness than permission. In my mind, this is very different from asserting that it is better to do so. Imagine for a moment that one works in a large bureaucracy. It’s long been my assertion (yes, that’s me) that the main function of bureaucracy is to deny access to scarce resources. To say “no”, in other words. In such a system, asking to do something within the bounds and via the methods of the bureaucracy (asking permission) is virtually guaranteed to result in denial. After all, if you could do it already, you wouldn’t need to ask permission; and if you couldn’t do it already, there’s a reason. Hence it’s easier to ask forgiveness here than permission simply because asking permission entails a process or requires that one be invented. But it’s not better, per se, because it’s risky. Turning the phrase to suggest it’s better to ask forgiveness than permission is to say that none of the regulatory structure on which bureaucracy functions matters. You are, in fact, likely to break something.