Does Code Decay? Assessing the Evidence from Change Management Data
By S. Eick, T. Graves, Alan F. Karr, James Stephen Marron, Audris Mockus. IEEE Trans. Software Eng., 2001
720 citations recorded by the source corpus.
Subfields: Computer Networks and Communications, Information Systems, Software
View Paper: https://www.semanticscholar.org/paper/a42c232f35d6b0336147eea280436e1d13dba2c3
How researchers see this paper
The researchers whose trusted networks rank it highest, strongest advocate first. Every researcher gets a different order.
In Computer Networks and Communications
In Information Systems
- James D. Herbsleb
- Audris Mockus
- Carliss Y. Baldwin
- Ahmed E. Hassan
- Alan MacCormack
- John Rusnak
- Htet Htet Aung
- Amy J. Ko
In Software
- Ahmed E. Hassan
- Htet Htet Aung
- James D. Herbsleb
- Amy J. Ko
- Brad A. Myers
- Eva Van Emden
- Audris Mockus
- Eleni Stroulia
Citations in the corpus
- Java quality assurance by detecting code smells (2002, methodology): “Such an approach seems feasible since analysis of this type of data has already been done, for example, in the context of software evolution research [2, 9].”
- An Exploratory Study of How Developers Seek, Relate, and Collect Relevant Information during Software Maintenance Tasks (2006, background): “Because these parts are typically distributed throughout a system’s components and modules [18], [30], this exploration can be both time-consuming and difficult.”
- An Empirical Study of Speed and Communication in Globally Distributed Software Development (2003, background): “This may reflect constraints about where the relevant expertise is, the addition of new people and sites that must be given some of the work even if the coupling to other work is tighter than one would like, or it may reflect a tendency of a software architecture to deteriorate over time so as to li”
- Distance, dependencies, and delay in a global collaboration (2000, background): “This may reflect constraints about where the relevant expertise is, the addition of new people and sites that must be given some of the work even if the coupling to other work is tighter than one would like, or it may reflect a tendency of a software architecture to deteriorate over time so as to li”
- UMLDiff: an algorithm for object-oriented design differencing (2005, methodology): “For example, the tuple <read, match_up, [100, 150, 3], [400, 475, 5]> represents the change: field of id 100 is read by method of id 150 in the original version; this relation also holds in the subsequent version with their counterparts, field of id 400 and method of id 475.”
- Predicting faults using the complexity of code changes (2009, methodology): “studied the concept of code decay and used the change history to create visualization of the change history of a project [9, 10].”
- The New C Standard (Excerpted material) An Economic and Cultural Commentary (2008, neutral): “line,[137] or a hundred million[106]) programs over many years,[106, 156, 331] and significant growth over a few years.”
- Exploring the Structure of Complex Software Designs: An Empirical Study of Open Source and Proprietary Code (2006, background): “, Eppinger et al. 1994, Ulrich 1995, Sanderson and Uzumeri 1995, Sanchez and Mahoney 1996, Schilling 2000). For example, Henderson and Clark (1990) show that incumbent firms often stumble when faced with innovations that are “architectural” in nature.”
- Exploring the Duality between Product and Organizational Architectures: A Test of the Mirroring Hypothesis (2012, positive): “Subsequent authors built on this work, proposing metrics to capture the level of “coupling” between modules and “cohesion” within modules (e.g., Selby and Basili, 1988; Dhama, 1995).”