Four interesting ways in which history can teach

Four “interesting” ways in which history can teach us about software Michael W. Godfrey * Xinyi Dong Cory Kapser Lijie Zou Software Architecture Group (SWAG) University of Waterloo *Currently on sabbatical at Sun Microsystems University of Waterloo

4. Longitudinal case studies of software manufacturing-related artifacts Q: How much maintenance effort is put into SM artifacts, relative to the system as a whole? • Studying six OSSs: – GCC, Postgre. SQL, kepler, ant, mycore, midworld • All used CVS; we examined their logs • We look for SM artifacts (Makefile, build. xml, SConscript) and compared them to non-SM artifacts

4. Longitudinal case studies of software manufacturing-related artifacts • Some results: – Between 58 and 81 % of the core developers contributed changes to SM artifacts – SM artifacts were responsible for • 3 -10% of the number of changes made • Up to 20% of the total LOC changed (GCC) • Open questions: – How difficult is it to maintain these artifacts? – Do different SM tools require different amounts of effort?

Challenges in this field 1. Dealing with scale 1. “Big system analysis” times “many versions” 2. Research tools often live at bleeding edge, slow and produce voluminous detail 2. Automation 1. Research tools often buggy, require handholding 1. Often, hard to get automated multiple analyses.

Challenges in this field 3. Artifact linkage and analysis granularity 1. Repositories (CVS, Unix fs) often store only source code, with no special understanding of, say, where a particular method resides. 2. (How) should we make them smarter? 1. e. g. , ctags and CCfinder 4. [Your thoughts? ]