Rules of the Order: The Sociology of Large, Multi-Institutional Software Development Projects

Digital Humanities is increasingly turning toward tool
development, both as a research modality and as a practical
means of exploiting the vast collections of digital resources
that have been amassing over the last twenty years. Like the
creation of digital collections, software development is an
inherently collaborative activity, but unlike digital collections,
complex software systems do not easily allow for loosely
aggregated collaborations. With digital text collections, it
might be possible to have several contributors working at
their own pace—even at several institutions—with a high
level of turnover and varying local workfl ows, but this is rarely
possible with software development. However discretized the
components of a system might be, the fi nal product is invariably
a tightly integrated whole with numerous dependencies and a
rigidly unifi ed architectural logic.
For most digital humanities practitioners, amassing a team of
developers almost requires that work be distributed across
institutions and among a varied group of people. Any nontrivial application requires experts from a number of different
development subspecialties, including such areas as interface
design, relational database management, programming,
software engineering, and server administration (to name only
a few). Few research centers in DH have the staff necessary
for undertaking large application development projects, and
even the ones that do quickly fi nd that crossdepartmental
collaborations are needed to assemble the necessary
expertise.
There are a great many works on and studies of project
management for software development, but very few of these
resources address the particular situation of a widely distributed
group of developers. Most of the popular methodologies
(Rational Unifi ed Process, Theory of Contraints, Event Chain)
assume a group of developers who are all in one place with
a clear management structure. More recent “agile methods”
(such as Extreme Project Management) invariably stipulate a
small groups of developers. Reading the ever useful (if slightly
dispiriting) works on project failure, such as Brooks’s famous
1975 book The Mythical Man Month, one wonders whether
project success is even possible for a distributed group.
Development of open source software might seem an
instructive counter-example of project success arising from
massive, distributed teams of developers, but as several studies
have shown, the core development team for even the largest
software development projects (Apache, Mozilla, and the
Linux kernel, for example) are considerably smaller than the
hundreds of people listed as contributors might suggest, and
in most cases, the project was able to build upon a core code
base that was originally developed in a single location with
only a few developers.
The MONK Project, which endeavors to build a portable
system for undertaking text analysis and visualization with
large, full text literary archives, might seem a perfect storm
of management obstacles. The project has two primary
investigators, half a dozen co-investigators, nearly forty
project participants at eight different institutions, and includes
professors of all ranks, staff programmers, research fellows,
and graduate students. The intended system, moreover,
involves dozens of complex components requiring expertise
in a number of programming languages, architectural principles,
and data storage methods, and facility with a broad range of
text analytical techniques (including text mining and statistical
natural language processing).
This paper offers some refl ections on the trials and triumphs
of project management at this scale using the MONK Project
as an example. It focuses particularly on the sociology of
academia as a key element to be acknowledged in management
practice, and concludes that honoring existing institutional
boundaries and work patterns is essential to maintaining a
cohesive (if, fi nally, hierarchical) management structure. It also
considers the ways in which this apparently simple notion runs
counter to the cultural practices and decision making methods
of ordinary academic units—practices which are so ingrained
as to seem almost intuitive to many.
The MONK Project has from the beginning studiously avoided
references to cloisters and habits in its description of itself.
This paper offers a playful analogy in contrast to that tradition,
by suggesting that most of what one needs to know about
project management was set forth by Benedict of Nursia
in his sixth-century Rule for monks. Particular emphasis is
placed on Benedict’s belief that social formations become
increasingly fractured as they move from the cenobitic ideal
(which, I suggest, is roughly analogous to the structure of the
typical research center), and his belief that the Abbot (like the
modern project manager) must assert a kind of benevolent
despotism over those within his charge, even if the dominant
values of the group privilege other, more democratic forms of
leadership.
References
Benedict of Nursia. Regula. Collegeville, Minn.: Liturgical Press,
1981.
Brooks, Frederick. The Mythical Man Month: Essays on Software
Development. Reading, MA: Addison-Wesley, 1975.
DeCarlo, Douglas. Extreme Project Management. New York:
Wiley-Jossey, 2004.
Kruchten, Philippe. The Rational Unifi ed Process: An Introduction.
3rd ed. Reading, Mass: Addison-Wesley, 2003.
Leach, Lawrence P. Critical Chain Project Management. 2nd ed.
Norwood, MA.: Artech, 2004.
Digital Humanities 2008 _____________________________________________________________________________
_____________________________________________________________________________
21
Mockus, Audris. Roy T. Fielding, James D. Herbsleb. “Two Case
Studies of Open Source Software Development: Apache
and Mozilla.” ACM Transactions on Software Engineering and
Methodology 11.3 (2002): 309-46.
Skinner, David C. Introduction to Decision Analysis. 2nd ed.
Sugar Land, TX: Probabilistic, 1999.