Ernst, Neil & John Mylopoulos. “Tracing software evolution history with design goals.” Software Evolvability, 2007 Third International IEEE Workshop on, Paris, 2007, pp. 36-41.

• This piece tries to trace why particular software designs work and why others don’t. The authors claim that understanding innovation is important in determining future innovations. The authors argue that design history should be extended to software artifacts and introduces the following for tracing software evolution: 1) requirements analysis; 2) technology context; and 3) social context. The authors attempt to do this tracing in the domain of distributed computing protocols. Ultimately “We conclude with observations drawn from this history that suggest designing software for evolvability must consider the history of similar application sin the requirements analysis” (36).
• The authors note that there is no formal history of software. What does exist in “IT and innovation management” is a financial tracing of how companies maximize value on IT spending.
• What’s contextual about software evolution? Software requirements “are high-level expressions of intentions, describing a need in the environment that can be met by instantiation in software” (ibid).
• Why do this work? 1) studying change in technology is one way of understanding the broader context of a technological problem; 2) To trace the problems and lessons so future developers don’t repeat the same work unnecessarily.
• A key point here: gaining access to the software development and design process is a key component of conducting a cultural-historical analyses using RGS. Closed source projects don’t provide access to the requirements analysis phase and also lack documentation for different iterations of a given software project. So, what are the ideal spaces of doing this kind of research: open-source projects where tracing a successful design and implementation over time can be documented in detail. (36)
• METHOD & DATA: What serves as data in this kind of tracing? 1) design decisions; 2) rationale for design; 3) requirements that motivated each implementation or proposal. The authors use this data to compare with subsequent design decisions, rationales and requirements to construct a narrative for how a particular design became successful.
• What are the actual documents in this analysis? 1) code; 2) mailing list/listservs/forums; 3) release-specific documentation; and 4) READMEs. You might also add documentation on things found in something like GitHub. They also include: 1) published specs and proposals for each protocol/iteration as well as 2) histories of the software industry at specific times to provide historical context. Finally, the authors also intuit a bit about the de facto intentions of the protocol (37).
• Definition of protocol: “standardized descriptions of resources and processes designed to maximize interoperability” (ibid).

Keywords: software evolution, design history, qualitative methodology, software history