Hey, do you use Drupal on a site with several thousand nodes? Do you also use the Apache Solr Integration module? If you’re like me, you’ve probably needed to reindex your site but couldn’t be bothered to wait for those pesky cron runs to finish – in fact, that’s what led me to file a feature request on the module to begin with.

Well, fret no more, because thanks to me and Greg Kallenberg, my illustrious fellow Applications Developer at NYPL DGTL, you can finally use Drupal’s Batch API to reindex your site. The module is available as an attachment from that same issue node on drupal.org. Nota bene: this is a really rough module, with code swiped pretty shamelessly from the Example Use of the Batch API page on drupal.org. It works, though, and it works well enough as we tear stuff down and build it back up over and over again.

The major roadblock that I’ve found is that working with Drupal requires a little bit of a paradigm shift if you’re used to using MVC frameworks like Rails, Django, or Zend. Instead, Drupal follows more of the PAC paradigm - a subtle difference, to be sure, but an important one. To me, the most important difference is the hierarchical structure of the paradigm, which is well suited to representing hierarchical structures of information (n.b.: I’ll be writing more on this elsewhere, as I have an external project to talk about at some point). Regardless, once you shift your thinking to doing a few things in Drupal, you may experience the burning desire to do everything in Drupal. Occasionally, it can be contagious!

A week ago today, a few of my DEG colleagues and I went to see Liz Lawley from RIT’s Lab for Social Computing give a talk entitled “Libraries as Happiness Engines.” It was a modified version of a talk she gave at this year’s CiL conference. The gist of the talk was that gaming in libraries means not just using established games to draw the public into the library, but also to begin implementing game mechanics into libraries that allow them to flourish as social spaces. In particular, these game mechanics include things like collecting, points, feedback, exchanges, and customization.

I’ve been ruminating on this for the last week or so in a couple different ways. First of all, I’ve been trying to figure out how we could implement game mechanics within NYPL.

A lot of the work that we’ve been doing involves developing a social space for both NYPL staff and the public through our site redesign. However, I still wonder motivates a patron to interact with us using our website. Right now, the only “social” aspect of our site is the ability to comment on blog posts - how can we expand this? At a basic, collection-focused level, we could develop a simple online scavenger hunt using materials in the NYPL Digital Gallery. We don’t need to have prizes - as Lawley and game theorist Jane McGonigal suggest, friendly competition is motivation enough for people to participate and to continue participating in games.

I’ve also been thinking about what it would take to put together an alternate reality game within a large institution like NYPL or a forecasting game involving libraries. I’ve been really fascinated by the creation of Superstruct, a project of the Institute for the Future, and since a Superstruct scenario was created by the American Association of Museums:

It’s 2019. Your museum is informed that an international group currently touring your building was exposed to the latest deadly strain of Respiratory Distress Syndrome. You are instructed to lock down the museum and shelter staff and visitors in place while authorities determine whether anyone is infected. Are you prepared to deal with this?

Other snapshots from 2019: Is your museum ready to help your community cope with an influx of refugees fleeing climate change, food shortages and political upheaval? How will your operations change in the face of soaring energy prices or collapse of the food production and distribution system? Your museum depends on its website to deliver information and attract visitors, but your content has been corrupted repeatedly in the past few months by hackers attempting to undermine your credibility. How do you adapt?

In addition, the Luce Foundation Center at the Smithsonian American Art Museum has developed an ARG called Ghosts of a Chance, wherein players create artifacts for display that also unlock further parts of the game. As this post on the blog Museum 2.0 says, ARGS require narrative consistency that is incredibly demanding; as such, cultural heritage institutions may be weary to participate as they might have to open their practices to greater scrutiny and mislead patrons intentionally to advance the narrative of the game. City Mystery, one of the producers of Ghosts of a Chance apparently “develop[s] and deliver[s] alternate reality games to benefit city libraries, museums, and other cultural institutions.” What I want to know is what other institutions have employed City Mystery (their website is as vague as the entry points for many ARGS!). Also, why are libraries so far behind museums in this regard? Public libraries need to get into the ARG business - drawing people in for ludic reasons might really help draw them in when they are in the mode of information seeking. In addition, ARGs are often driven by information seeking behavior. Why shouldn’t we think of using them as a means to make library instruction fun?

Getting up to speed is hard anywhere, and it’s especially difficult in a large, complex institution like NYPL. Other than just understanding the projects that you’re given, you also are thrown headfirst into making sense of the culture, the organization, and all the unspoken and occasionally unseen things that allow you to do your job. There’s no clear place to start this, so a good portion of the time you have to keep on top of that while you start thrashing away at your work. The question remains, though, how do you organize this stuff? How do you enable sensemaking in yourself and your peers?

I don’t have a definitive answer, and I haven’t entirely decided how to do this on day-to-day or sustainable terms. I’ve found myself relying on various things to begin this process of cognitive ordering. Basecamp couldn’t do it all, so Jay and I threw together Labs Code in an hour or so. There are still plenty of other things that Labs Code can’t track, so I started throwing things like meeting minutes I typed up in various places. I keep dreaming of one big bucket to capture it all, but there’s none in sight. I also keep asking myself the same set of questions over and over again: “Other people do this here, right?” “Why can’t we do this collectively for every one of our projects?”

I don’t have an answer for these questions either, but I’ve been looking for answers elsewhere by reading voraciously, as is my wont. I recently finished Scott Rosenberg’s Dreaming In Code, and I’m almost finished with Frederick Brooks‘ The Mythical Man-Month. These books are both inspirationally and terrifyingly educational as I watch scenarios from both of these works play out with projects here.

Dreaming In Code describes Mitch Kapor’s project to put together truly revolutionary, open source PIM software (hey, knowledge organization!). The project resulted in Chandler, which just hit 1.0 last month. It’s a fair characterization of software development between the idealization of wanting to get something cool out the door and the reality that you can’t really get anything done without a clear idea of what you’re supposed to be doing. Rosenberg invokes Brooks’ work repeatedly, as we watch the Chandler team run into the full force of “Brooks’ Law” over and over again: Adding manpower to a late software project makes it later. Brooks reworks this into a more comprehensible statement: Adding people to a software project increases the total effort necessary in three ways: the work and disruption of repartitioning itself, training the new people, and added intercommunication. As Labs grows, I see (and have seen) us getting tripped up in the same way.

The twenty-fifth anniversary edition of The Mythical Man-Month also reprints an essay entitled “No Silver Bullet — Essence and Accident in Software Engineering.” Brooks warns us that “there is no single development, in either technology or management technique” that will reliably make software development run more smoothly. However, the rest of The Mythical Man-Month provides a fair number of suggestions on how to organize people and information to make things run slightly more smoothly.

I understand that any methodology might not be our silver bullet for slaying the werewolf, but we need to start somewhere. Clearly defined specifications are obviously not fun to write, but everyone feels better once they’re done. It’s easier to put tangible deadlines on things when you know all the constituent tasks. In addition, I know that I’d greatly benefit from having project managers around to resolve disputes or help me get resources when needed rather than me having to do that and, so to speak, be on the shoproom floor.

The final question for the time being is how to begin this when you’ve only had only occasional contact with this sort of thing. I never worked as a developer before, and I know I can’t just waltz in and begin espousing Scrum or whatever. How do you begin writing specs when you don’t know how? How detailed do you go? It’s clear we need them, though, because the werewolves, vampires, and demons have been stalking us for far too long! If we can’t find our silver bullet, let’s band together and at least build some pitchforks.