Context: The Google Play Store allows app developers to respond to user reviews. Existing research shows that response strategies vary considerably. In addition, while responding to reviews can lead to several types of favorable outcomes, not every response leads to success, which we define as increased user ratings.

Background. The software architecture recovery method RELAX produces a concern-based architectural view of a software system graphically and textually from that system's source code. The method has been implemented in software which can recover the architecture of systems whose source code is written in Java. Aims. Our aim was to find out whether the availability of architectural views produced by RELAX can help maintainers who are new to a project in becoming productive with development tasks sooner, and how they felt about working in such an environment. Method. We conducted a user study with nine participants. They were subjected to a controlled experiment in which maintenance success and speed with and without access to RELAX recovery results were compared to each other. Results. We have observed that employing architecture views produced by RELAX helped participants reduce time to get started on maintenance tasks by a factor of 5.38 or more. While most participants were unable to finish their tasks within the allotted time when they did not have recovery results available, all of them finished them successfully when they did. Additionally, participants reported that these views were easy to understand, helped them to learn the system's structure and enabled them to compare different versions of the system. Conclusions. Through the speedup to the start of maintenance experienced by the participants as well as in their formed opinions, RELAX has shown itself to be a valuable help that could provide the basis of further tools that specifically support the development process with a focus on maintenance.

Until recently, communications regarding apps on the iOS App Store have been one-way from users to developers, with developers unable to respond to reviews directly. While studies have shown that responding to reviews improves an app's overall rating and user satisfaction, resource limitations make it so developers can usually only respond to some of the reviews. Although developers' response behavior has been studied, little is known about which features (aspects) of user reviews spur their responses. Motivated by these observations, we investigate a wide range of features that can be extracted from a user review and apply a random forest algorithm and the features it extracts to predict whether developers will respond to that review. We then determine the importance of these features in distinguishing reviews that receive a developer response from those that do not. Through a case study of three popular free-to-download iOS apps, we find that although features such as rating and review length are among the most important features for all apps, each app has its own individual feature importance ranking, indicating that developers assign different feature weights when prioritizing reviews. Our results may help guide research or the development of tools that are more in line with developers' actual response behavior.

Background: Which aspects of an iOS App Store user review motivate developers to respond? Numerous studies have been conducted to extract useful information from reviews, but limited effort has been expended to answer this question.

Prior work on mobile app reviews has demonstrated that user reviews contain a wealth of information and are seen as a potential source of requirements. However, most of the studies done in this area mainly focused on mining and analyzing user reviews from the US App Store, leaving reviews of users from other countries unexplored. In this paper, we seek to understand if the perception of the same apps between users from other countries and that from the US differs through analyzing user reviews. We retrieve 300,643 user reviews of the 15 most downloaded iOS apps of 2018, published directly by Apple, from nine English-speaking countries over the course of 5 months. We manually classify 3,358 reviews into several software quality and improvement factors. We leverage a random forest based algorithm to identify factors that can be used to differentiate reviews between the US and other countries. Our preliminary results show that all countries have some factors that are proportionally inconsistent with the US.

Background: Researchers oftentimes measure quality metrics only in the changed files when analyzing software evolution over commit-history. This approach is not suitable for compilation and using program analysis techniques that require byte-code. At the same time, compiling the whole software not only is costly but may also leave us with many uncompilable and unanalyzed revisions. Aims: We intend to demonstrate if analyzing changes in a module results in achieving a high compilation ratio and a better understanding of software quality evolution. Method: We conduct a large-scale multi-perspective empirical study on 37838 distinct revisions of the core module of 68 systems across Apache, Google, and Netflix to assess their compilability and identify when the software is uncompilable as a result of a developer's fault. We study the characteristics of uncompilable revisions and analyze compilable ones to understand the impact of developers on software quality. Results: We achieve high compilation ratios: 98.4% for Apache, 99.0% for Google, and 94.3% for Netflix. We identify 303 sequences of uncompile commits and create a model to predict uncompilability based on commit metadata with an F1-score of 0.89 and an AUC of 0.96. We identify statistical differences between the impact of affiliated and external developers of organizations. Conclusions: Focusing on a module results in a more complete and accurate software evolution analysis, reduces the cost and complexity, and facilitates manual inspection.

Software systems are often developed by many developers who have a varying range of skills and habits. These developers have a big impact on software quality. Understanding how different developers and developer characteristics impact the quality of a software is crucial to properly deploy human resources and help managers improve quality outcomes which is essential for software systems success. Addressing this concern, we conduct a study on how different developers and developer characteristics such as developer seniority in a system, frequency of commits, and interval between commits relate to Technical Debt (TD). We performed a large-scale analysis on 19,088 commits from 38 Apache Java systems and applied multiple statistical analysis tests to evaluate our hypotheses. Our empirical evaluation suggests that developers unequally increase and decrease TD, a developer seniority in a software system and frequency of commits are negatively correlated with the TD the developer induces, and a developer commit interval has a positive correlation with the TD the developer induces.

Developers intend to improve the quality of the software as it evolves. However, as software becomes larger and more complex, those intended actions may lead to unintended consequences. Analyzing change in software quality among different releases overlooks fine-grained changes that each commit introduces. We believe that studying software quality before and after each commit (commit-impact analysis) can reveal a wealth of information about how the software evolves and how each change impacts its quality. In this paper, we explore whether each commit has an impact on the source code, investigate the compilability of each impactful commit, examine how source code changes affect software quality metrics, and study the effectiveness of using a certain metric as software quality indicator. We analyze a total of 19,580 commits from 38 Apache Java software systems to better understand how change occurs, why, and by who.