Towards an Evidence-Based Understanding of Emergence of Architecture through Continuous Refactoring in Agile Software Development – A Summary

The popularity of Agile Software Development approach gave rise to many questions related to the architecture of the system developed. According to architecture-centric developers, failure in resolving architecture related problems could lead to software architecture erosion and thus failure of the software projects. The objective of this research was to determine the possibility of extracting a satisfactory architecture from refactoring the developed software and the role of the contextual factor in it, as it could help avoid architecture erosion while following Agile Software Development approach reducing cost and incorporate changes into the software. The objective of this paper was to collect empirical evidence supporting it. Surveys and semi-structured interviews via email were conducted with selected candidates of varying experiences and skill sets, while the collected data was analyzed using Grounded Theory. One of the observations made in agile approaches was the fact that the developers while trying to incorporate the Agile manifesto into their work started to pay little attention to the architecture related process considering an optional task. Scrum followers claimed to support architectural practices via oral communication. According to Scrum, the software’s architecture can be refactored and repackaged into components. Crystal Clear model considers software architecture development and domain models a compulsory part of it. In general, agile methods emphasize on the process of software architecture’s emergence from small and continuous refactoring of the developed software whereas the architecture-centric developers believe in developing the architecture during the early levels of software development lifecycle. According to the results obtained 68% of the test group claimed that there did exist a possibility of software architecture emergence from refactoring the developed software among which only 59% of the total test group claimed the contextual factors being the reason for it. A total of 20 contextual factors were not only identified but also classified into 4 categories i.e. project, team, organization, and practices. In the ‘project’ category, the probability of software architecture’s emergence from refactoring is found to be greater if the size of the project is small while consisting of several features with overall low algorithmic complexity, having a system design based on contemporary design principles and technology, and a development team having a required set of architecture knowledge and also the knowledge about the type of architecture significant requirements and their criticality. When looking into the category ‘team’ the task was successful if the team size was smaller consisting of experienced people with a required set of skills and having the urge to learn new technologies and to adopt with them. When talked about the category ‘practices’, continuous integration and good design principles of a system lead to the emergence of software architecture from small refactoring of the software. Good management support, communicational skills, organizational structure, organizational governance, and maturity also resulted in the emergence of software architecture from small and continuous refactoring. Although the findings of this research paper should be taken into consideration for devising a suitable strategy to deal with architectural aspects, there does exist a threat to the validity of this empirical research in terms of the right set of selected candidates for this research, and the applicability and usefulness of this research. This paper also emphasized on the fact that there should be more empirical research conducted on the aspects related to the contextual factors identified in this research.