Working group members: Kimmy Szeto, William R. Vanden Dries (group leader)
This group was tasked with discussing the difference between the conventional waterfall model of software development and the rapid application development as exemplified in MARC vs. BIBFRAME.
The terms “agile” and “waterfall” denote two very different approaches to software development. Waterfall development originated in hardware manufacturing, and preceded agile development. Waterfall development begins with a clear picture of the design requirements and advances in a linear way until the launchable product is assembled during the last phase. Waterfall development only advances from one phase to the next after the current phase is complete. Once a phase is complete, the project does not return to a previous phase, even if mistakes are found. When mistakes are identified, a choice must be made: either push forward despite the errors, or start over at the beginning. In time, many software developers adopted a more agile approach to avoid this inherent problem of waterfall development.
Agile development is characterized by shorter development phases, commonly referred to as “sprints,” and a modular design structure that includes multiple specialized groups working on different, but connected, aspects of development. At the end of each sprint a launchable, or nearly launchable, product is generated, allowing for testing and feedback at every phase. Feedback is gathered through testing and from the various development groups. This feedback influences further development, altering design requirements along the way to increase the product’s usability and to align the product more closely with clients’ needs.
MARC development incorporated aspects of both waterfall and agile development over its long development history. During the MARC pilot project, data was shipped to participating libraries across the country on physical tapes. Feedback was gathered during the pilot project by telephone and by mail. One particularly influential piece of feedback during MARC II development was the interest displayed by libraries outside of the United States. Their interest shifted the communication model of MARC from a one to many model (i.e. the LC Distribution Service) to one that also included sharing among organizations [Avram, 6-7]. A second significant change made at the end of the pilot project was an extension of the character set for roman alphabet languages [Avram, 7]. The initial MARC design did not foresee these two changes at the outset, but approached these opportunities from an agile development perspective. Successful redirection and design was implemented in these areas without a complete redesign of the MARC system.
While MARC development was, and continues to be, agile in some respects, it resembled a waterfall development style in others. Largely due to the time constraints on the initial MARC pilot project in 1966, the MARC I format was designed to create stable records for one format: books [Avram, 5]. Additional incremental changes were necessary if the MARC format was to become compatible with not only books, but all forms of material. Over a period of several years following the MARC pilot project, specialists in several fields including serials, maps, films, and manuscripts contributed to further development of the MARC format [Avram, 10]. Unfortunately, the music cataloging community was one of the later communities to provide specialist feedback to MARC. Many limitations identified and changes proposed by the music cataloging community were never implemented, due to the inertia built up by MARC prior to this specialist feedback. This resulted in significant inadequacies in the MARC format’s ability to accurately represent the bibliographic relationships essential to understanding musical works and their instances. The choice was made: push forward despite known bugs in the code.
[Some examples of where the waterfall development of MARC has really and seriously hindered our work would be helpful to include here. Please contribute suggestions if you have any!]
BIBFRAME is a significant opportunity to improve music resource discovery by addressing MARC’s inadequate handling of printed music and sound recordings. Decades of research into bibliographic relationships give BIBFRAME a starting point far ahead of where MARC was in 1965. However, the choice between an agile, waterfall, or combined approach must still be made, making it possible to repeat mistakes made during MARC development. Hindsight shows us that MARC development benefitted more from an agile approach than a waterfall approach.
Therefore, this task force makes this strong recommendation: Keep BIBFRAME development agile. Incorporate the voice of MLA and other specialist organizations. Revisit development early and often.
The BIBFRAME Implementation testbed is comparable to the MARC pilot project. Today, just as during the MARC pilot project, institutions participating in the BIBFRAME testbed are expected to submit feedback on their experience. Feedback received through the testbed will be just as valuable as the feedback gathered during the MARC pilot project. Furthermore, just as the cataloging community continued to identify necessary changes to MARC long after the pilot project officially ended, limitations of BIBFRAME will be identified long after the implementation testbed is closed. Don’t let bugs in BIBFRAME persist because of a waterfall approach if they can be fixed by keeping BIBFRAME agile.
Avram, Henriette D. MARC, its history and implications. Washington: Library of Congress, 1975.