As Connie mentioned in her blog post this week, we started building the website for our archive. For me, it’s typically nerve-racking to start to show work in process. This is especially true on a subject that I find fascinating and worthy of exploration for beyond the end product due for this class. After hearing some conflicting ideas about how to proceed given the fact that we felt uncertain about the usefulness of our research and archival collection, we both agreed that trying to build something sooner might give us insight into the state of our research thus far.  One method of overcome hesitation to build/publish on my part was to channel the inner technical project/program manager bag of tricks I’ve collected with my professional experience over the last ten years.

The most influential software development practices theory over the last three decades are found under the Agile Development umbrella. As such, I found some strength to start building out the website for our archive in the  Manifesto for Agile Software Development. One value statement from that concise document I’ve always held close to me while working with software engineers is “working software over comprehensive documentation.” The principal behind this software cardinal virtue elaborated in the Principles behind the Agile Manifesto:
“working software is the primary measure of progress.” One important caveat to the values espoused in the Agile Manifesto, each of which is formulated with the favored value in the left, and the diminished value on the right, is that “while there is value in the items on
the right, we value the items on the left more.” One can assert that planning and documentation play a role in the development of a digital project in the context of digital humanities. Certainly it’s true when it comes to acquiring funding for a digital initiative. Still, a plan and documentation pale somewhat to having the digital project manifest itself, in this case, as a website. Consequently, I used the agile rationale to dive head first into creating a repo and generating some version of our archive on the web using Wax.

Another source of inspiration came in the form of software engineering management wisdom gleaned from the development of IBMs OS/360, the operation system developed for the company’s System/360 mainframe. Fred Brook’s The Mythical Man-Month details the learning he culled from his experience managing the OS/360, germinating from a question IBM’s CEO asked Brooks during his exit interview on why managing a software project seemed significantly difficult in comparison to a hardware project. While the book is clearly from a particular time and place in history, some of the lessons learned feel durable even in the face of increased processing power and more ergonomic/productive programming technologies. One chapter, “Plan to Throw One Away” felt appropriate to address any hesitation I might feel in starting our web archive as soon as possible. As Brooks sees it:

In most projects, the first system built is barely usable.There is no alternative but to start again, smarting but smarter, and build a redesigned version in which…problems are solved…one has to build a system to throw away, for even the best planning is not omniscient as to get it right the first time. The management question, there, is not whether to build a pilot system and throw it away. You will do that. The only question is whether to plan in advance to build a throwaway, or to promise to deliver the throwaway to customers…Hence plan to throw one away; you will, anyhow (Brooks, 116).

In an attempt to embrace this lesson, we’ve started to assemble our metadata in the csv without overthinking it, and knowing that we won’t get the filters and categorizations right the first time, but that in doing the work will yield the lessons for a reversion. Similarly, we’re dumping our entire photo catalog into the website as a first step. While some curation has already taken plan in the creation of our collection, we need to see all of the assets in one place to understand if any of them won’t work for our archive for one reason or another. I’ve also embraced the throwaway nature of some of the initial work in the naming conventions in our code: the collection at present is called temp_collection and we reuse templates from the Wax demo project as a starting off point. Even the repo name is wax-project, obviously is nondescript name. The key motivation is to get something working, even if we’ll eventually replace a great deal of it. Once we have a website up and running, we can critique it, file bugs and changes requests to it, and create a new version that better addresses our needs.

Citations

Brooks, Frederick Phillips. The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley, 1995.