Static Code Analysis (SCA) tools play a vital role in software development, reducing the cost and time required for code reviews. However, high false-positive and false-negative rates are reported for the best tools in the community. Accordingly, studies often aim to develop datasets for learning SCA warning patterns to reduce false positive results. These datasets are meant to possess high-quality and high-volume in covering the full range of faults/rules that typically result in false warnings and be compliant with established coding standards. However, existing studies have not utilised such datasets or identified the breadth of rules that are prone to false-positives and their compliance to coding standards. We analysed code from Stack Overflow and Apache Tomcat to capture variations in code length and style in detecting false-positive warnings from best-performing tools PMD and SonarQube, addressing this gap. In deriving false-positive warnings, outcomes from the tools were labelled using established coding standards. Deeper analyses were then conducted to identify the rules that are prone to false-positives, reasons for these, and agreement/gaps between SCA rules and established standards. Among our main outcomes, we observe that only a few SCA rules generate false-positives, ranging from 4.64% to 18.45% across four datasets. Additionally, eliminating rules that contradict established standards significantly reduce the false-positive rate. Additionally, our findings reveal discrepancies between tools and established standards. Given the evidence established in this study, we recommend further investigations into gaps between tools and established standards, including the use of machine learning approaches to annotate larger datasets.

Large language models (LLMs) have demonstrated impressive capabilities in code generation, achieving high scores on benchmarks such as HumanEval and MBPP. However, these benchmarks primarily assess functional correctness and neglect broader dimensions of code quality, including security, reliability, readability, and maintainability. In this work, we systematically evaluate the ability of LLMs to generate high-quality code across multiple dimensions using the PythonSecurityEval benchmark. We introduce an iterative static analysis-driven prompting algorithm that leverages Bandit and Pylint to identify and resolve code quality issues. Our experiments with GPT-4o show substantial improvements: security issues reduced from >40% to 13%, readability violations from >80% to 11%, and reliability warnings from >50% to 11% within ten iterations. These results demonstrate that LLMs, when guided by static analysis feedback, can significantly enhance code quality beyond functional correctness.

In supporting the development of high-quality software, especially necessary in the era of LLMs, automated program repair (APR) tools aim to improve code quality by automatically addressing violations detected by static analysis profilers. Previous research tends to evaluate APR tools only for their ability to clear violations, neglecting their potential introduction of new (sometimes severe) violations, changes to code functionality and degrading of code structure. There is thus a need for research to develop and assess comprehensive evaluation frameworks for APR tools. This study addresses this research gap, and evaluates Sorald (a state-of-the-art APR tool) as a proof of concept. Sorald’s effectiveness was evaluated in repairing 3,529 SonarQube violations across 30 rules within 2,393 Java code snippets extracted from Stack Overflow. Outcomes show that while Sorald fixes specific rule violations, it introduced 2,120 new faults (32 bugs, 2088 code smells), reduced code functional correctness—as evidenced by a 24% unit test failure rate—and degraded code structure, demonstrating the utility of our framework. Findings emphasize the need for evaluation methodologies that capture the full spectrum of APR tool effects, including side effects, to ensure their safe and effective adoption.

Agile methods and associated practices have been held to deliver value to software developers and customers. Research studies have reported team productivity and software quality benefits. While such insights are helpful for understanding how agile methods add value during software development, there is need for understanding the intersection of useful practices and outcomes over project duration. This study addresses this opportunity and conducted an observation study of student projects that was complemented by the analysis of demographics data and open responses about the challenges encountered during the use of agile practices. Data from 22 student teams comprising 85 responses were analyzed using quantitative and qualitative approaches, where among our findings we observed that the use of good coding practices and quality management techniques were positively correlated with all dimensions of product quality (e.g., functionality scope and software packaging). Outcomes also reveal that software product quality was predicted by requirements scoping, team planning and communication, and coding practice. However, high levels of team planning and communication were not necessary for all software development activities. When examining project challenges, it was observed that lack of technical skills and poor time management present most challenges to project success. While these challenges may be mitigated by agile practices, such practices may themselves create unease, requiring balance during project implementation.

Large Language Models (LLMs), such as GPT models, are increasingly used in software engineering for various tasks, such as code generation, requirements management, and debugging. While automating these tasks has garnered significant attention, a systematic study on the impact of varying hyperparameters on code generation outcomes remains unexplored. This study aims to assess LLMs' code generation performance by exhaustively exploring the impact of various hyperparameters. Hyperparameters for LLMs are adjustable settings that affect the model's behaviour and performance. Specifically, we investigated how changes to the hyperparameters-temperature, top probability (top_p), frequency penalty, and presence penalty-affect code generation outcomes. We systematically adjusted all hyperparameters together, exploring every possible combination by making small increments to each hyperparameter at a time. This exhaustive approach was applied to 13 Python code generation tasks, yielding one of four outcomes for each hyperparameter combination: no output from the LLM, non-executable code, code that fails unit tests, or correct and functional code. We analysed these outcomes for a total of 14,742 generated Python code segments, focusing on correctness, to determine how the hyperparameters influence the LLM to arrive at each outcome. Using correlation coefficient and regression tree analyses, we ascertained which hyperparameters influence which aspect of the LLM. Our results indicate that optimal performance is achieved with a temperature below 0.5, top probability below 0.75, frequency penalty above -1 and below 1.5, and presence penalty above -1. We make our dataset and results available to facilitate replication.

Abstract Software cross-project defect prediction (CPDP) makes use of cross-project (CP) data to overcome the lack of data necessary to train well-performing software defect prediction (SDP) classifiers in the early stage of new software projects. Since the CP data (known as the source) may be different from the new project’s data (known as the target), this makes it difficult for CPDP classifiers to perform well. In particular, it is a mismatch of data distributions between source and target that creates this difficulty. Transfer learning-based CPDP classifiers are designed to minimize these distribution differences. The first Transfer learning-based CPDP classifiers treated these differences equally, thereby degrading prediction performance. To this end, recent research has the Weighted Balanced Distribution Adaptation (W-BDA) method to leverage the importance of both distribution differences to improve classification performance. Although W-BDA has been shown to improve model performance in CPDP and tackle the class imbalance by balancing the class proportion of each domain, research to date has failed to consider model performance in light of increasing target data. We provide the first investigation studying the effects of increasing the target data when leveraging the importance of both distribution differences. We extend the initial W-BDA method and call this extension the W-BDA $$\mathbf {^{+}}$$ + method. To evaluate the effectiveness of W-BDA $$\mathbf {^{+}}$$ + for improving CPDP performance, we conduct eight experiments on 18 projects from four datasets, where data sampling was performed with different sampling methods. Data sampling was only performed on the baseline methods and not on our proposed W-BDA $$\mathbf {^{+}}$$ + and the original W-BDA because data sampling issues do not exist for these two methods. We evaluate our method using four complementary indicators (i.e., Balanced Accuracy, AUC, F-measure and G-Measure). Our findings reveal an average improvement of 6%, 7.5%, 10% and 12% for these four indicators when W-BDA $$\mathbf {^{+}}$$ + is compared to the original W-BDA and five other baseline methods (for all four of the sampling methods used). Also, as the target to source ratio is increased with different sampling methods, we observe a decrease in performance for the original W-BDA, with our W-BDA $$\mathbf {^{+}}$$ + approach outperforming the original W-BDA in most cases. Our results highlight the importance of having an awareness of the effect of the increasing availability of target data in CPDP scenarios when using a method that can handle the class imbalance problem.

Abstract Just-In-Time (JIT) defect prediction aims to identify defects early, at commit time. Hence, developers can take precautions to avoid defects when the code changes are still fresh in their minds. However, the utility of JIT defect prediction has not been investigated in relation to crashes of mobile apps. We therefore conducted a multi-case study employing both quantitative and qualitative analysis. In the quantitative analysis, we used machine learning techniques for prediction. We collected 113 reliability-related metrics for about 30,000 commits from 14 Android apps and selected 14 important metrics for prediction. We found that both standard JIT metrics and static analysis warnings are important for JIT prediction of mobile app crashes. We further optimized prediction performance, comparing seven state-of-the-art defect prediction techniques with hyperparameter optimization. Our results showed that Random Forest is the best performing model with an AUC-ROC of 0.83. In our qualitative analysis, we manually analysed a sample of 642 commits and identified different types of changes that are common in crash-inducing commits. We explored whether different aspects of changes can be used as metrics in JIT models to improve prediction performance. We found these metrics improve the prediction performance significantly. Hence, we suggest considering static analysis warnings and Android-specific metrics to adapt standard JIT defect prediction models for a mobile context to predict crashes. Finally, we provide recommendations to bridge the gap between research and practice and point to opportunities for future research.

While the software engineering community (i.e., those involved with engineering software) is constantly in search of insights into team atmosphere and group dynamics and the way these issues impact team performance, little opportunities typically exist to explore this issue. Student projects offer an opportunity for us to understand these issues, and particularly if these students are on the verge of leaving university for post-study work and using similar practices to those used in industry. We explore a range of student software development projects’ data and students’ open-ended responses to five group dynamics categories: communication, time management, commitment, problem analysis and solving, and initiative and involvement. We analyse both quantitative and qualitative data to study the variation in group dynamics across teams developing different software and how these variations correlated with team satisfaction. We also explore the group dynamics themes that evolve from students’ open responses in relation to the five categories. Furthermore, we relate the prevalence of the themes to various software development performance metrics, before exploring the opportunity of predicting an optimum team dynamics. We observe variations in the way different teams work, but higher performing teams also committed more to their projects. Various group dynamics themes were evident among functional teams, and specific patterns were more pronounced when teams were productive. Further, while there is no specific group dynamics pattern that predicts project success, successful teams were most organised and reflective. Competence may set the tone for positive group dynamics and team performance. Also, an achievement-driven orientation is as important as the soft skills and interpersonal aspects.

The need for collective intelligence in technology means that online Q&A platforms, such as Stack Overflow and Reddit, have become invaluable in building the global knowledge ecosystem. Despite literature demonstrating a prevalence of inclusion and contribution disparities in online communities, studies investigating the underlying reasons behind such fluctuations remain scarce. The current study examines Stack Overflow users’ contribution profiles, both in isolation and relative to various diversity metrics, including GDP and access to electricity. This study also examines whether such profiles propagate to the city and state levels, supplemented by granular data such as per capita income and education, before validating quantitative findings using content analysis. We selected 143 countries and compared the profiles of their respective users to assess implicit diversity-related complications that impact how users contribute. Results show that countries with high GDP, prominent R&D presence, less wealth inequality and sufficient access to infrastructure tend to have more users, regardless of their development status. Similarly, cities and states where technology is more prevalent (e.g., San Francisco and New York) have more users who tend to contribute more often. Qualitative analysis reveals distinct communication styles based on users’ locations. Urban users exhibited assertive, solution-oriented behaviour, actively sharing information. Conversely, rural users engaged through inquiries and discussions, incorporating personal anecdotes, gratitude and conciliatory language. Findings from this study may benefit scholars and practitioners, allowing them to develop sustainable mechanisms to bridge the inclusion and diversity gaps.

There is an increasing recognition that computing education and the profession of computing has failed indigenous learners around the world. In this paper we argue for a reform of tertiary education's computing curricula so that they address the needs of both indigenous and non-indigenous learners. To achieve this, we must first consider the role of computing as a negative colonising force that continues to the present. This paper integrates traditional methods of storytelling to provide context for a reframing of computing as a decolonising force. A case study of the New Zealand context where Mori have been underserved by both computing education and the computing profession, is used to identify systemic barriers. We propose a process of partnership that empowers indigenous communities to work with industry and education to imagine a computing profession that positively contributes to thriving decolonised practice. And then how can computer science education contribute to that? We then canvas some potential directions a transformation of computing education might take. This paper is not intended to replace or pre-empt partnerships or indigenous self-determination, but to inspire computer science educators towards developing an approach that improves outcomes for all learners.

There is an increasing recognition that computing education and the profession of computing has failed indigenous learners around the world. ACM has responded to this through a focus on diversity, equity and inclusion. This Special Session progresses this work by bringing together diverse voices in panel and audience to look towards a decolonised future for CSEd. This Session integrates traditional methods of storytelling to provide context for a reframing of computing as a decolonising force. We start with sharing stories of the impact of colonised computing, then use these as motivation for envisioning the role and shape a transformation of computing education might take. The session concludes with an exercise on options for Indigenous communities and their allies such as ACM to form partnerships to empower Indigenous communities to work with industry and education to imagine a computing profession and CS education that positively contributes to thriving decolonised practice. This session is aimed at all who are interested in progressing the CS curriculum towards a thriving, equitable and inclusive CSEd experience for Indigenous and non-Indigenous learners.

Abstract A key function of a software system is its ability to facilitate the manipulation of data, which is often implemented using a flavour of the Structured Query Language (SQL). To develop the data operations of software (i.e, creating, retrieving, updating, and deleting data), developers are required to excel in writing and combining both SQL and application code. The problem is that writing SQL code in itself is already challenging (e.g., SQL anti-patterns are commonplace) and combining SQL with application code (i.e., for SQL development tasks) is even more demanding. Meanwhile, we have little empirical understanding regarding the characteristics of SQL development tasks. Do SQL development tasks typically need more code changes? Do they typically have a longer time-to-completion? Answers to such questions would prepare the community for the potential challenges associated with such tasks. Our results obtained from 20 Apache projects reveal that SQL development tasks have a significantly longer time-to-completion than SQL-unrelated tasks and require significantly more code changes. Through our qualitative analyses, we observe that SQL development tasks require more spread out changes, effort in reviews and documentation. Our results also corroborate previous research highlighting the prevalence of SQL anti-patterns. The software engineering community should make provision for the peculiarities of SQL coding, in the delivery of safe and secure interactive software.

Software developers make use of on crowdsourcing during development. Beyond learning from others, developers use online portals such as Stack Overflow as a vehicle for collaboration. However, little is known about developers’ experiences on such platforms, particularly around problems that are encountered online. Such insights could benefit software developers in terms of recommendations for pitfalls to avoid, ways to exploit crowdsourced knowledge, and the provision of insights to improve online code sharing communities. We interviewed 50 practitioners to fill this gap, where outcomes show that software developers’ use of online portals is targeted, and such portals are a lifeline to modern software development. Practitioners are facilitated with code solutions and debugging, often in a very timely fashion. While these experiences are largely positive, practitioners also encounter negative experiences online, some of which could be significantly deleterious to the community. We discuss the implications of these findings, such as creating awareness of the quality and reliability of code snippets, improving code searches, code validation and outdated code detection and attribution of code snippets.

Cross-project defect prediction (CPDP) models are used in new software project prediction tasks to improve defect prediction rates. The development of these CPDP models could be challenging in cases where there is little or no historical data. For this reason, researchers may need to rely on multiple sources and use transfer learning-based CPDP for building defect prediction models. These data are typically taken from similar and related projects, but their distributions can be different from the new software project (target data). Although, transfer learning-based CPDP models are designed to handle these distribution differences, but if not correctly handled by the model, may lead to negative transfer. To this end, recent works have focused on building transfer CPDP models, but little is known about how similar or dissimilar sources should be to avoid negative transfer. This paper provides the first empirical investigation to understand the effect of combining different sources with different levels of similarities in transfer CPDP. We introduce the use of the Population Stability Index (PSI) to interpret whether the distribution of the combined or single-source data is similar to the target data. This was validated using an adversarial approach. Experimental results on three public datasets reveal that when the source and target distribution are very similar, the probability of false alarm is improved by 3% to 7% and the recall indicator is reduced from 1% to 8%. Interestingly, we also found that when dissimilar source data are combined with different source datasets, the overall domain divergence is lowered, and the performance is improved. The results highlight the importance of using the right source to aid the learning process.

Stack Overflow is used to solve programming issues during software development. Research efforts have looked to identify relevant content on this platform. In particular, researchers have proposed various modelling techniques to predict acceptable Stack Overflow answers. Less interest, however, has been dedicated to examining the performance and quality of typically used modelling methods with respect to the model and feature complexity. Such insights could be of practical significance to the many practitioners who develop models for Stack Overflow. This study examines the performance and quality of two modelling methods, of varying degree of complexity, used for predicting Java and JavaScript acceptable answers on Stack Overflow. Our dataset comprised 249,588 posts drawn from years 2014-2016. Outcomes reveal significant differences in models’ performances and quality given the type of features and complexity of models used. Researchers examining model performance and quality and feature complexity may leverage these findings in selecting suitable modelling approaches for Q&A prediction.

Together with many success stories, promises such as the increase in production speed and the improvement in stakeholders’ collaboration have contributed to making agile a transformation in the software industry in which many companies want to take part. However, driven either by a natural and expected evolution or by contextual factors that challenge the adoption of agile methods as prescribed by their creator(s), software processes in practice mutate into hybrids over time. Are these still agile? In this article, we investigate the question: what makes a software development method agile? We present an empirical study grounded in a large-scale international survey that aims to identify software development methods and practices that improve or tame agility. Based on 556 data points, we analyze the perceived degree of agility in the implementation of standard project disciplines and its relation to used development methods and practices. Our findings suggest that only a small number of participants operate their projects in a purely traditional or agile manner (under 15 percent). That said, most project disciplines and most practices show a clear trend towards increasing degrees of agility. Compared to the methods used to develop software, the selection of practices has a stronger effect on the degree of agility of a given discipline. Finally, there are no methods or practices that explicitly guarantee or prevent agility. We conclude that agility cannot be defined solely at the process level. Additional factors need to be taken into account when trying to implement or improve agility in a software company. Finally, we discuss the field of software process-related research in the light of our findings and present a roadmap for future research.

Short-term events, like hackathons, are commonly applied to innovate on novel subject areas and on ground-breaking technologies. While such events have led to significant successful outcomes for many companies, the big questions facing organisers of these events are: "where do we start?, what should be done towards the hosting of a successful event?, and what should be done when the event is completed?" While several methods and supporting recommendations have been introduced for answering these questions, a common framework for the hosting and management of short-term events is still not available. This is a limitation, as having such a framework would allow organisers to carry out systematic analysis for the subject area, identify the most suitable pre-event analysis and support functions, combine these with the fitting and justified short-term event types, and carry the results of the event to fruitful, sustainable businesses with post-event operations. The opportunity to progress events into business ventures is particularly noteworthy given the rapid changes that are typical in the technology domain, and thus, the need to be both innovative and nimble in responding to such changes and ensuing opportunities. To fill this gap, we introduce an evidence-driven framework for hosting short-term events. Our framework presents several chronological modules coupled together to form a comprehensive, but agile set of practices. A review of the state-of-the-art and a partial empirical trial support the framework’s utility, notwithstanding the need for further work to enhance and trial the framework for organising other events.

Requirements prioritisation deals with the ranking or classification of user requirements based on their importance. This process is central to releasing a software product with features most favoured by users. While studies have explored the efforts that are dedicated to this cause, these tend to focus on a subset of the solutions that are available in the software engineering domain. Current techniques investigated in the software engineering domain do not consider the strengths inherent in requirements prioritisation techniques developed in other disciplines (e.g. product manufacturing), a gap that should be addressed. The authors thus conducted a comprehensive systematic mapping study and critical evaluation of studies that have provided implementations of requirements prioritisation techniques across multiple disciplines (including software engineering, product manufacturing, and engineering). Among their findings, they observed that while many solutions are targeted, quite often researchers have proposed solutions that were not evaluated. Most solutions were only validated as being operational, and the attributes studied had limited effects on performance outcomes. Their evidence suggests that new techniques may address the requirements prioritisation challenge if they are inspired by hybrid approaches developed across multiple disciplines. In addition, performance trade-offs are to be expected of such techniques, depending on their performance targets.

Context: Stack Overflow is a popular community question and answer portal used by practitioners to solve problems during software development. Developers can focus their attention on answers that have been accepted or where members have recorded high votes in judging good answers when searching for help. However, the latter mechanism (votes) can be unreliable, and there is currently no way to differentiate between an answer that is likely to be accepted and those that will not be accepted by looking at the answer's characteristics. Objective: In potentially providing a mechanism to identify acceptable answers, this study examines the features that distinguish an accepted answer from an unaccepted answer. Methods: We studied the Stack Overflow dataset by analyzing questions and answers for the two most popular tags (Java and JavaScript). Our dataset comprised 249,588 posts drawn from 2014-2016. We use random forest and neural network models to predict accepted answers, and study the features with the highest predictive power in those two models. Results: Our findings reveal that the length of code in answers, reputation of users, similarity of the text between questions and answers, and the time lag between questions and answers have the highest predictive power for differentiating accepted and unaccepted answers. Conclusion: Tools may leverage these findings in supporting developers and reducing the effort they must dedicate to searching for suitable answers on Stack Overflow.

Since software systems are designed to satisfy customers' needs, developers have an obligation to address users' requirements and demands logged via issue trackers and other forums. Having to respond to a large number of requests while developing and perfecting systems presents prioritization challenges, however. Android Operating System (OS) developers have largely overcome this obstacle by responding to specific user requests, which may be traced back to actual software code changes, providing lessons for the software engineering community. This study applies text and data mining techniques to investigate the Android community as an ecosystem, exploring how developers responded to issues raised by the community over several versions of the OS. Results show a strong relationship between issues raised by the community and developer responses to these issues. This relationship also extended to actual source code changes made by developers. Furthermore, the findings show a correlation between user requests and developer responses enacted via code changes across specific Android versions and important functionalities. This evidence suggests that developers have invested in the Android platform to guarantee its survival and overall success, largely through addressing user demands. We outline implications for software engineering professionals and software systems success.

This paper investigates how developers discuss code smells and anti-patterns over Stack Overflow to understand better their perceptions and understanding of these two concepts. Understanding developers' perceptions of these issues are important in order to inform and align future research efforts and direct tools vendors in the area of code smells and anti-patterns. In addition, such insights could lead the creation of solutions to code smells and anti-patterns that are better fit to the realities developers face in practice. We applied both quantitative and qualitative techniques to analyse discussions containing terms associated with code smells and anti-patterns. Our findings show that developers widely use Stack Overflow to ask for general assessments of code smells or anti-patterns, instead of asking for particular refactoring solutions. An interesting finding is that developers very often ask their peers 'to smell their code' (i.e., ask whether their own code 'smells' or not), and thus, utilize Stack Overflow as an informal, crowd-based code smell/anti-pattern detector. We conjecture that the crowd-based detection approach considers contextual factors, and thus, tends to be more trusted by developers over automated detection tools. We also found that developers often discuss the downsides of implementing specific design patterns, and 'flag' them as potential anti-patterns to be avoided. Conversely, we found discussions on why some anti-patterns previously considered harmful should not be flagged as anti-patterns. Our results suggest that there is a need for: 1) more context-based evaluations of code smells and anti-patterns, and 2) better guidelines for making trade-offs when applying design patterns or eliminating smells/anti-patterns in industry.

Context: Contemporary software development is typically conducted in dynamic, resource-scarce environments that are prone to the accumulation of technical debt. While this general phenomenon is acknowledged, what remains unknown is how technical debt specifically manifests in and affects software processes, and how the software development techniques employed accommodate or mitigate the presence of this debt. Objectives: We sought to draw on practitioner insights and experiences in order to classify the effects of agile method use on technical debt management, given the popularity and perceived success of agile methods. We explore the breadth of practitioners’ knowledge about technical debt; how technical debt is manifested across the software process; and the perceived effects of common agile software development practices and processes on technical debt. In doing so, we address a research gap in technical debt knowledge and provide novel and actionable managerial recommendations. Method: We designed, tested and executed a multi-national survey questionnaire to address our objectives, receiving 184 responses from practitioners in Brazil, Finland, and New Zealand. Results: Our findings indicate that: 1) Practitioners are aware of technical debt, although, there was under utilization of the concept, 2) Technical debt commonly resides in legacy systems, however, concrete instances of technical debt are hard to conceptualize which makes it problematic to manage, 3) Queried agile practices and processes help to reduce technical debt; in particular, techniques that verify and maintain the structure and clarity of implemented artifacts (e.g., Coding standards and Refactoring) positively affect technical debt management. Conclusions: The fact that technical debt instances tend to have characteristics in common means that a systematic approach to its management is feasible. However, notwithstanding the positive effects of some agile practices on technical debt management, competing stakeholders’ interests remain a concern.

One of the purported ways to increase productivity and reduce development time is to reuse existing features and modules. If reuse is adopted, logically then, it will have a direct impact on a system's evolution. However, the evidence in the literature is not clear on the extent to which reuse is practiced in real-world projects, nor how it is practiced. In this paper we report the results of an investigation of reuse and evolution of software features in one of the largest open-source ecosystems - Eclipse. Eclipse provides a leading example of how a system can grow dramatically in size and number of features while maintaining its quality. Our results demonstrate the extent of feature reuse and evolution and also patterns of reuse across ten different Eclipse releases (from Europa to Neon).

Context: The validity of survey-based research depends on, amongst other considerations, the number and validity of obtained data points. As with any empirical study that involves practitioners, collecting data via surveys is difficult. Objectives: We report our experiences derived while conducting an industry survey on the impact of agile practices on software process quality. Method: After unsuccessfully trying to collect data with an online questionnaire, we used an interactive approach with posters at practitioners-focussed software engineering community events to aid data collection. Results: We present a list of lessons learnt. In particular, the poster-based data collection approach provided utility, for both gathering a large amount of responses and facilitating follow-up interactions with study participants. Conclusion: Our experiences in this work may help those facing challenges associated with obtaining responses from practitioners through the use of potentially complex questionnaires.

Requirements engineering is assessed as the most important phase of the software development process. This process is especially challenging for app developers, who tend to gather crowd-based feedback after releasing their apps. This feedback is often voluminous, posing prioritization challenges for developers identifying features to fix or add. While previous work has identified frequently mentioned features, and some effort has been dedicated towards providing various prioritization and classification techniques, these do not quite address the prioritization challenge faced by app developers given voluminous app reviews. In fact, there is also need to assess the scale of app reviews' usefulness. We use content analysis and regression to contribute towards this cause by exploring the usefulness of app reviews, and the attributes that predict which app features to fix, respectively. Our outcomes show that reviews tended to either provide information of little value (i.e., no actionable information) or highlighted problems that may directly affect the functionality of app features. For two different apps, we also observe that features that were mentioned the most (the feature frequency attribute) in lower ranked reviews provided by users had the strongest predictive power for identifying severely broken features (as perceived by a developer). However, the ordering did not match with the frequency with which reports were made by users. There were also variances in the attributes that predict which features to fix, for the reviews of different apps. Review mining and prioritization challenges remain given variances in app reviews' content and structure. These findings also point to the need to redesign app review interfaces to consider how reviews are captured.

Platforms such as Stack Overflow are available for software practitioners to solicit help and solutions to their challenges and knowledge needs. This community's practices have in recent times however caused quality-related concerns. Academic work tends to provide validation for the practice and processes of these forums, however, previous work did not review the scale of scientific attention that is given to this cause. We conducted a Systematic Mapping study involving 266 papers from six relevant databases to address this gap. In this preliminary work we explored the level of academic interest Stack Overflow has generated, the publication venues, the topics studied and approaches used. Outcomes show that Stack Overflow has attracted increasing research interest, with topics relating to both community dynamics and human factors, and technical issues. In addition, research studies have been largely evaluative or proposed solutions, though this latter approach tends to lack validation. This signals the need for future work to explore the nature of Stack Overflow research contributions that are provided, and their quality. We outline our research agenda for continuing with such efforts.

Context: Open Source Software (OSS) developers use mailing lists as their main forum for discussing the evolution of a project. However, the use of mailing lists by developers for decision-making has not received much research attention. Objective: We have explored this issue by studying developers' email discussions around Python Enhancement Proposals (PEPs). Method: Our dataset comprised 42,672 emails from six different mailing lists pertaining to PEP development. We performed multiple forms of analysis on these emails, involving both quantitative measures (e.g., frequency) and deeper analysis of specific PEP discussions (i.e., outlier analysis). Results: Out of three PEP types (Informational, Process and Standard Track), Standard Track PEPs attract a large amount of discussion (both in volume and average number of messages per proposal). Our study also identified specific PEP states and topics that generated a disproportionate amount of discussion. Conclusion: Our outcomes point to several opportunities for improving the management of an OSS team based on the knowledge generated from discussions. We have also identified several interesting avenues for future work such as identifying individuals or groups that present persuasive arguments during decision-making.

User-reviews of mobile applications provide information that benefits other users and developers. Even though reviews contain feedback about an app's performance and problematic features, users and app developers need to spend considerable effort reading and analyzing the feedback provided. In this work, we introduce and evaluate QuickReview, an intelligent user interface for reporting problematic app features. Preliminary user evaluations show that QuickReview facilitates users to add reviews swiftly with ease, and also helps developers with quick interpretation of submitted reviews by presenting a ranked list of commonly reported features.

In seeking to complement consultants' and tool vendors' reports, there has been an increasing academic focus on understanding the adoption and use of software development methods and practices. We surveyed practitioners working in Brazil, Finland, and New Zealand in a transnational study to contribute to these efforts. Among our findings we observed that most of the 184 practitioners in our sample focused on a small portfolio of projects that were of short duration. In addition, Scrum and Kanban were used most; however, some practitioners also used conventional methods. Coding Standards, Simple Design and Refactoring were used most by practitioners, and these practices were held to be largely suitable for project and process management. Our evidence points to the need to properly understand and support a wide range of software methods.

The process by which norms are developed to become policies, the normative decision-making process, is not often explicit to stakeholders of Open Source Software (OSS) projects. Understanding the normative decision-making process is crucial for members if such projects are to evolve and succeed. In this paper, we investigated aspects of the normative decision-making processes of OSS development through the use of Python Enhancement Proposals (PEPs). We compared extracted process models with those that are advertised by the Python community to evaluate the extent to which those processes overlap. In addition, we assess members' involvement and contribution to these processes. Our work used structural and behavioral analysis techniques, and social network analysis metrics. We found that there were differences between the extracted processes and Python's advertised process, with the extracted processes being significantly more complex. These differences also extended to granular models used for managing social and technical aspects of the Python project. Furthermore, some key members were largely responsible for PEPs' success. Our extracted models could go a far way in helping the Python community to quickly understand decision-making processes in Python.

App reviews contain valuable feedback about what features should be fixed and improved. This feedback could be 'mined' to facilitate app maintenance and evolution. While requirements are routinely extracted from post-release users' feedback in traditional projects, app reviews are often generated by a much larger client-base with competing needs and priorities and ad hoc structure. Although there has been interest aimed at exploring the nature of issues reported in app reviews (e.g., bugs and enhancement requests), prioritizing these outcomes for improving and evolving apps hasn't received much attention. In this preliminary study we aim to bridge this gap by proposing three prioritization approaches. Driven by literature in other domains, we identify four attributes (frequency, rating, negative emotions and deontics) that serve as the base constructs for prioritization. Thereafter, using these four constructs, we develop three approaches (individual attribute-based approach, weighted approach and regression-based approach) that may help developers to prioritize features for improvements. We evaluate our approaches in constructing multiple prioritized lists of features using reviews from the MyTracks app. It is anticipated that these prioritized lists could allow developers to better focus their efforts in deciding which aspects of their apps to improve.

Noting the overwhelming speed during software development, and particularly in environments where rapid delivery is the norm, the lack of accumulated technical debt information could result in ineffective management. We introduce technical debt propagation channels in this paper to advance software maintenance research on two accounts: (1) We describe the fundamental components for the channels, allowing identification of distinct channels, and (2) we describe a procedure to identify and abstract technical debt channels in order to produce technical debt propagation models. Our propagation models pursue automation of technical debt information maintenance with program analysis results, and translation of the maintained information between existing-and currently disconnected-technical debt management solutions. We expect the immediate technical debt information to enhance applicability and effectiveness of existing technical debt management approaches.

Context: Post-release user feedback plays an integral role in improving software quality and informing new features. Given its growing importance, feedback concerning security enhancements is particularly noteworthy. In considering the rapid uptake of Android we have examined the scale and severity of Android security threats as reported by its stakeholders. Objective: We systematically mine Android issue logs to derive insights into stakeholder perceptions and experiences in relation to certain Android security issues. Method: We employed contextual analysis techniques to study issues raised regarding confidentiality and privacy in the last three major Android releases, considering covariance of stakeholder comments, and the level of consistency in user preferences and priorities. Results: Confidentiality and privacy concerns varied in severity, and were most prevalent over Jelly Bean releases. Issues raised in regard to confidentiality related mostly to access, user credentials and permission management, while privacy concerns were mainly expressed about phone locking. Community users also expressed divergent preferences for new security features, ranging from more relaxed to very strict. Conclusions: Strategies that support continuous corrective measures for both old and new Android releases would likely maintain stakeholder confidence. An approach that provides users with basic default security settings, but with the power to configure additional security features if desired, would provide the best balance for Android's wide cohort of stakeholders.

Context: Individuals' personality traits have been shown to influence their behavior during team work. In particular, positive group attitudes are said to be essential for distributed and global software development efforts where collaboration is critical to project success. Objective: Given this, we have sought to study the influence of global software practitioners' personality profiles from a psycholinguistic perspective. Method: Artifacts from ten teams were selected from the IBM Rational Jazz repository and mined. We employed social network analysis (SNA) techniques to identify and group practitioners into two clusters based on the numbers of messages they communicated, Top Members and Others, and used standard statistical techniques to assess practitioners' engagement in task changes associated with work items. We then performed psycholinguistic analysis on practitioners' messages using linguistic dimensions of the LIWC tool that had been previously correlated with the Big Five personality profiles. Results: For our sample of 146 practitioners, we found that the Top Members demonstrated more openness to experience than the Other practitioners. Additionally, practitioners involved in usability-related tasks were found to be highly extroverted, and coders were most neurotic and conscientious. Conclusion: High levels of organizational and inter-personal skills may be useful for those operating in distributed settings, and personality diversity is likely to boost team performance.

Context: Interest in software engineering (SE) methodologies and tools has been complemented in recent years by research efforts oriented towards understanding the human processes involved in software development. This shift has been imperative given reports of inadequately performing teams and the consequent growing emphasis on individuals and team relations in contemporary SE methods. Objective: While software repositories have frequently been studied with a view to explaining such human processes, research has tended to use primarily quantitative analysis approaches. There is concern, however, that such approaches can provide only a partial picture of the software process. Given the way human behavior is nuanced within psychological and social contexts, it has been asserted that a full understanding may only be achieved through deeper contextual enquiries. Method: We have followed such an approach and have applied data mining, SNA, psycholinguistic analysis and directed content analysis (CA) to study the way core developers at IBM Rational Jazz contribute their social and intellectual capital, and have compared the attitudes, interactions and activities of these members to those of their less active counterparts. Results: Among our results, we uncovered that Jazz's core developers worked across multiple roles, and were crucial to their teams' organizational, intra-personal and interpersonal processes. Additionally, although these individuals were highly task- and achievement-focused, they were also largely responsible for maintaining positive team atmosphere. Further, we uncovered that, as a group, Jazz developers spent a large amount of time providing context awareness in support of their colleagues. Conclusion: Our results suggest that high-performing distributed agile teams rely on both individual and collective efforts, as well as organizational environments that promote informal and organic work structures.

Context: Given the acknowledged need to understand the people processes enacted during software development, software repositories and mailing lists have become a focus for many studies. However, researchers have tended to use mostly mathematical and frequency-based techniques to examine the software artifacts contained within them. Objective: There is growing recognition that these approaches uncover only a partial picture of what happens during software projects, and deeper contextual approaches may provide further understanding of the intricate nature of software teams' dynamics. We demonstrate the relevance and utility of such approaches in this study. Method: We use psycholinguistics and directed content analysis (CA) to study the way project tasks drive teams' attitudes and knowledge sharing. We compare the outcomes of these two approaches and offer methodological advice for researchers using similar forms of repository data. Results: Our analysis reveals significant differences in the way teams work given their portfolio of tasks and the distribution of roles. Conclusion: We overcome the limitations associated with employing purely quantitative approaches, while avoiding the time-intensive and potentially invasive nature of field work required in full case studies.

Agile software developers are required to self-organize, occupying various informal roles as needed in order to successfully deliver software features.However, previous research has reported conflicting evidence about the way teams actually undertake this activity.The ability to self-organize is particularly necessary for software development in globally distributed environments, where distance has been shown to exacerbate human-centric issues.Understanding the way successful teams self-organise should inform distributed team composition strategies and software project governance.We have used psycholinguistics to study the way IBM Rational Jazz practitioners enacted various roles, expressed attitudes and shared competencies to successfully self-organize in their global projects.Among our findings, we uncovered that practitioners enacted various roles depending on their teams' cohort of features; and that team leaders were most critical to IBM Jazz teams' self-organisation.We discuss these findings and highlight their implications for software project governance.