The driving forces of API evolution

Evolving an Application Programming Interface (API) is a delicate activity, as modifications to them can significantly impact their users. The increasing use of APIs means that software development organisations must take an empirical and scientific approach to the way they manage the evolution of their APIs. If no attempt at analysing or quantifying the evolution of an API is made, there will be a diminished understanding of the evolution, and possible improvements to the maintenance strategy will be difficult to identify. We believe that long-standing software evolution theories can provide additional insight to the field of APIs, and can be of great use to companies maintaining APIs. In this case study, we conduct a qualitative investigation to understand what drives the evolution of an industry company's existing API, by examining two versions of the API interface. The changes were analysed based on two software evolution theories, and the extent to which we could reverse engineer the change decisions was determined by interviewing an architect of the API. The results of this analysis show that the largest driving force of the APIs evolution was the desire for new functionality. Our findings which show that changes happen sporadically, rather than continuously, appear to show that the law of Conservation of Organisational Stability was not a considerable factor for the evolution of the API. We also found that it is possible to reverse engineer change decisions and in doing so, identified that the feedback loop of an API is an important area of improvement.

[1]  Bennet P. Lientz,et al.  Software Maintenance Management: A Study of the Maintenance of Computer Application Software in 487 Data Processing Organizations , 1980 .

[2]  Ralph E. Johnson,et al.  The role of refactorings in API evolution , 2005, 21st IEEE International Conference on Software Maintenance (ICSM'05).

[3]  Zhenchang Xing,et al.  Refactoring Practice: How it is and How it Should be Supported - An Eclipse Case Study , 2006, 2006 22nd IEEE International Conference on Software Maintenance.

[4]  Per Runeson,et al.  Guidelines for conducting and reporting case study research in software engineering , 2009, Empirical Software Engineering.

[5]  Christine Nadel,et al.  Case Study Research Design And Methods , 2016 .

[6]  Meir M. Lehman,et al.  On understanding laws, evolution, and conservation in the large-program life cycle , 1984, J. Syst. Softw..

[7]  Romain Robbes,et al.  How do developers react to API deprecation?: the case of a smalltalk ecosystem , 2012, SIGSOFT FSE.

[8]  Miryung Kim,et al.  An Empirical Study of API Stability and Adoption in the Android Ecosystem , 2013, 2013 IEEE International Conference on Software Maintenance.

[9]  Joshua J. Bloch How to design a good API and why it matters , 2006, OOPSLA '06.

[10]  Daqing Hou,et al.  Exploring the Intent behind API Evolution: A Case Study , 2011, 2011 18th Working Conference on Reverse Engineering.

[11]  Ralph Johnson,et al.  How do APIs evolveq A story of refactoring: Research Articles , 2006 .

[12]  Izak Benbasat,et al.  The Case Research Strategy in Studies of Information Systems , 1987, MIS Q..

[13]  Ralph E. Johnson,et al.  How do APIs evolve? A story of refactoring , 2006, J. Softw. Maintenance Res. Pract..

[14]  Michi Henning API: Design Matters , 2007, ACM Queue.

[15]  Dewayne E. Perry,et al.  Metrics and laws of software evolution-the nineties view , 1997, Proceedings Fourth International Software Metrics Symposium.

[16]  E. Acosta Chaparro,et al.  Comparing API Design Choices with Usability Studies : A Case Study and Future Directions , 2006 .

[17]  Bertrand Meyer,et al.  An Empirical Study of API Usability , 2013, 2013 ACM / IEEE International Symposium on Empirical Software Engineering and Measurement.

[18]  J. Henkel,et al.  CatchUp! Capturing and replaying refactorings to support API evolution , 2005, Proceedings. 27th International Conference on Software Engineering, 2005. ICSE 2005..

[19]  J. Knottnerus,et al.  Real world research. , 2010, Journal of clinical epidemiology.

[20]  David G. Messerschmitt,et al.  Software Ecosystem: Understanding an Indispensable Technology and Industry , 2003 .

[21]  Jacob Cohen,et al.  Weighted kappa: Nominal scale agreement provision for scaled disagreement or partial credit. , 1968 .

[22]  E. B. Swanson,et al.  Software maintenance management , 1980 .

[23]  Clarisse Sieckenius de Souza,et al.  Evaluating application programming interfaces as communication artefacts , 2012, PPIG.

[24]  M.M. Lehman,et al.  Programs, life cycles, and laws of software evolution , 1980, Proceedings of the IEEE.

[25]  Tao Xie,et al.  An Empirical Study on Evolution of API Documentation , 2011, FASE.

[26]  Per Runeson,et al.  A spiral process model for case studies on software quality monitoring - method and metrics , 2007, Softw. Process. Improv. Pract..

[27]  Carolyn B. Seaman,et al.  Qualitative Methods in Empirical Studies of Software Engineering , 1999, IEEE Trans. Software Eng..

[28]  Ned Chapin,et al.  Types of software evolution and software maintenance , 2001, J. Softw. Maintenance Res. Pract..