This Article 
   
 Share 
   
 Bibliographic References 
   
 Add to: 
 
Digg
Furl
Spurl
Blink
Simpy
Google
Del.icio.us
Y!MyWeb
 
 Search 
   
Toward Understanding the Rhetoric of Small Source Code Changes
June 2005 (vol. 31 no. 6)
pp. 511-526
Dewayne E. Perry, IEEE Computer Society
Understanding the impact of software changes has been a challenge since software systems were first developed. With the increasing size and complexity of systems, this problem has become more difficult. There are many ways to identify the impact of changes on the system from the plethora of software artifacts produced during development, maintenance, and evolution. We present the analysis of the software development process using change and defect history data. Specifically, we address the problem of small changes by focusing on the properties of the changes rather than the properties of the code itself. Our study reveals that 1) there is less than 4 percent probability that a one-line change will introduce a fault in the code, 2) nearly 10 percent of all changes made during the maintenance of the software under consideration were one-line changes, 3) nearly 50 percent of the changes were small changes, 4) nearly 40 percent of changes to fix faults resulted in further faults, 5) the phenomena of change differs for additions, deletions, and modifications as well as for the number of lines affected, and 6) deletions of up to 10 lines did not cause faults.

[1] F. Brooks, The Mythical Man-Month. Addison-Wesley, 1975.
[2] M. Leszak, D.E. Perry, and D. Stoll, “Classification and Evaluation of Defects in a Project Retrospective,” J. Systems and Software, vol. 61, no. 3, pp. 173-187, 2002.
[3] A. Mockus and L.G. Votta, “Identifying Reasons for Software Changes Using Historic Databases,” Proc. Int'l Conf. Software Maintenance, pp. 120-130, Oct. 2000.
[4] T.L. Graves and A. Mockus, “Inferring Change Effort from Configuration Management Databases,” Proc. Fifth Int'l Symp. Software Metrics, pp. 267-273, 1998.
[5] S.G. Eick, T.L. Graves, A.F. Karr, J.S. Marron, and A. Mockus, “Does Code Decay? Assessing the Evidence from Change Management Data,” IEEE Trans. Software Eng., vol. 27, no. 1, Jan. 2001.
[6] D.E. Perry and H.P. Siy, “Challenges in Evolving a Large Scale Software Product,” Proc. Int'l Workshop Principles of Software Evolution (ICSE 1998), Apr. 1998.
[7] A. Mockus and D.M. Weiss, “Predicting Risk of Software Changes,” Bell Labs Technical J., pp. 169-180, Apr.-June 2000.
[8] R. Rogers, “Deterring the High Cost of Software Defects,” technical paper, Upspring Software, Inc., Year?
[9] G.M. Weinberg, “Kill That Code!” Infosystems, pp. 48-49, Aug. 1983.
[10] D.M. Weiss and V.R. Basili, “Evaluating Software Development by Analysis of Changes: Some Data from the Software Engineering Laboratory,” IEEE Trans. Software Eng., vol. 11, no. 2, pp. 157-168, Feb. 1985.
[11] M. Lipow, “Prediction of Software Failures,” The J. Systems and Software, pp. 71-75, 1979.
[12] E.B. Swanson, “The Dimensions of Maintenance,” Proc. Second Int'l Conf. Software Eng., pp. 492-497, Oct. 1976.
[13] T.L. Graves, A.F. Karr, J.S. Marron, and H. Siy, “Predicting Fault Incidence Using Software Change History,” IEEE Trans. Software Eng., vol. 26, no. 7, pp. 653-661, July 2000.
[14] H.E. Dunsmore and J.D. Gannon, “Analysis of the Effects of Programming Factors on Programming Effort,” The J. Systems and Software, pp. 141-153, 1980.
[15] I.-H. Lin and D.A. Gustafson, ”Classifying Software Maintenance,” Proc. IEEE, pp. 241-247, 1988.
[16] D.E. Perry, H.P. Siy, and L.G. Votta, “Parallel Changes in Large Scale Software Development: An Observational Case Study,” ACM Trans. Software Eng. and Methodology, vol. 10, no. 3, pp 308-337, July 2001.
[17] L. Hatton, “Reexamining the Fault DensityComponent Size Connection,” IEEE Software, vol. 14, no. 2, pp. 89-97, Mar./Apr. 1997.
[18] V.R. Basili and B.T. Perricone, “Software Errors and Complexity: An Empirical Investigation,” Comm. ACM, vol. 27, no. 1, pp. 42-52, Jan. 1984.
[19] D.E. Perry and W.M. Evangelist, “An Empirical Study of Software Interface Errors,” Proc. Int'l Symp. New Directions in Computing, pp. 32-38, Aug. 1985.
[20] D.E. Perry and W.M. Evangelist, “An Empirical Study of Software Interface FaultsAn Update,” Proc. 20th Ann. Hawaii Int'l Conf. Systems Sciences, pp. 113-126, Jan. 1987.
[21] G.J. Holtzmann, “The Logic of Bugs,” Proc. 10th ACM SIGSOFT Symp. Foundations of Software Eng. (FSE-10), pp. 81-87, Nov. 2002.
[22] K.E. Martersteck and A.E. Spencer, “Introduction to the 5ESSTM Switching System,” AT&T Technical J., vol. 64, no. 6, pp. 1305-1314, July-Aug. 1985.
[23] D.C. Carr, A. Dandekar, and D.E. Perry, “Experiments in Process Interface Descriptions, Visualizations and Analyses,” Proc. European Workshop Software Process Technology, pp. 119-137, 1995.
[24] L.G. Votta and M.L. Zajak, “Design Process Improvement Case Study Using Process Waiver Data,” Proc. European Software Eng. Conf., pp. 44-58, 1995.
[25] P.A. Tuscany, “Software Development Environment for Large Switching Projects,” Proc. Sixth Int'l Conf. Software Eng., pp. 58-67, Sept. 1992.
[26] M.J. Rochkind, “The Source Code Control System,” IEEE Trans. Software Eng., vol. 1, no. 4, pp. 364-370, Dec. 1975.
[27] M.M. Lehman, D.E. Perry, and J.F. Ramil, “Implications of Evolution Metrics on Software Maintenance,” Proc. Int'l Conf. Software Maintenance, 1998.
[28] CVSConcurrent Versions System, http:/www.cvshome.org, 2004.
[29] D.B. Leblang, “The CM Challenge: Configuration Management that Works,” Configuration Management: Trends in Software, W.F. Tichy, ed., John Wiley and Sons, 1994.
[30] A.E. Hassan, “Mining Software Repositories to Assist Developers and Support Managers,” PhD thesis, Dept. of Computer Science, Univ. of Waterloo, Feb. 2005.
[31] A.E. Hassan and R.C. Holt, “Studying the Chaos of Code Development,” Proc. WCRE 2003: Working Conf. Reverse Eng., Nov. 2003.
[32] S.G. Eick, J.L. Steffen, and E.E. Sumner Jr., “SeesoftA Tool for Visualizing Line Oriented Software Statistics,” IEEE Trans. Software Eng., vol. 18, no. 11, pp. 957-968, Nov. 1992.
[33] J. Meltzoff, Critical Thinking about Research: Psychology and Related Fields. Washington D.C.: Psychological Assoc., 1997.
[34] D.E. Perry, “An Empirical Approach to Design Metrics and Judgments,” Proc. New Vision for Software Design and Production Workshop, Dec. 2001.

Index Terms:
Index Terms- Source code changes, software faults, one-line changes, fault probabilities.
Citation:
Ranjith Purushothaman, Dewayne E. Perry, "Toward Understanding the Rhetoric of Small Source Code Changes," IEEE Transactions on Software Engineering, vol. 31, no. 6, pp. 511-526, June 2005, doi:10.1109/TSE.2005.74
Usage of this product signifies your acceptance of the Terms of Use.