Context: Debugging is a critical practice in software engineering that enables software engineers to ensure the correctness of code by identifying and resolving bugs. It also benefits newcomers as it helps them go through the codebase, understand its structure, and learn about its functionality. Recent research has uncovered that some software engineering tools are not well suited to all ways of thinking, imposing an additional cognitive overhead on individuals whose cognitive styles are not well-supported by the tool. While biases have been explored in other software tools, little is known about whether debugging tools exhibit cognitive biases and introduce “inclusivity bugs”. Objective: This paper addresses this gap by examining inclusivity bugs that newcomers encounter when using the PyCharm debugger. Methods: In this study, we performed a controlled lab experiment where we observed 24 software engineering students with little to no experience as they used the PyCharm debugger for a set of tasks. We used a think-aloud protocol to capture participants’ thoughts throughout the experiment. Then, we conducted a thematic analysis, guided by our research question, to identify potential biases in the tool. We used the GenderMag framework to examine the relationship between cognitive style and the inclusivity bugs. Results: We detail our findings on 21 inclusivity bugs which are caused by 2 main reasons: discoverability and learnability. We identified trends that showed individuals with low self-efficacy, low motivation, risk-averse tendencies, and those who prefer to learn by processes and gather information selectively were the ones who faced the most challenges. Conclusion: The findings provide insights into how debuggers can be made more inclusive. They also highlight the need for continuous evaluation and adaptation of SE tools and practices to ensure they meet the needs of all users with diverse cognitive styles to ensure fairness.

Abstract Online user feedback, like app reviews, can provide valuable insights into software product improvements, offering development teams direct insights into customer experiences, preferences, and pain points. There are many studies that have proposed promising methods to automatically prioritize online user feedback, helping development teams identify the most salient software issues that need to be addressed. However, these methods may not take into account the accessibility-related needs of end users. Our study addresses this limitation by developing a novel approach to analyze and prioritize app store reviews that discuss accessibility concerns. This new approach involves the evaluation of seven distinct machine learning (ML) algorithms, as well as three state-of-the-art large language models (LLMs), all leveraging features of app reviews relevant to accessibility. Utilizing validated accessibility reviews, we assess the effectiveness of our proposed approach and compare its performance with a leading general prioritization tool. The results show that our novel method surpasses the leading general tool in prioritizing accessibility reviews, achieving an F1-score of 83.6%. This represents an improvement over the prior study’s F1-score of 69.0%. Additionally, our approach outperforms the existing method across all three priority classifications, with the most notable improvement seen in the identification of high-priority reviews, where we achieved a + 59.8% increase in F1-score. We hope our findings will inspire more research and innovation in this area and ultimately contribute to a more inclusive and accessible digital landscape for all users.

Abstract Libraries assist in accelerating the development of software applications by providing reusable functionalities. Libraries and applications that declare these libraries as dependencies become their clients. However, as libraries evolve, maintaining the dependencies in client projects can be challenging if the new version contains breaking changes. Yet, limited research focuses on analyzing the impact of breaking changes on client projects when updating dependencies in the wild. Hence, we conduct an empirical analysis using Java projects built using Maven to investigate the impact of breaking changes introduced between two library versions. Our dataset included 18,415 Maven artifacts, declaring 142,355 direct dependencies, out of which 71.60% were not up-to-date. We automatically updated these dependencies and discovered that 11.58% of the dependency updates resulted in breaking changes that affected the client, and almost half of them were introduced during a non-major update. We analyzed the changes in the libraries that contributed towards these breaking changes, and our results indicate that changes in transitive dependencies were a significant factor in introducing breaking changes. We further investigated if it was common for clients to use functionalities of transitive dependencies directly without declaring them. This showed that over half of the clients use transitive functionality. Therefore, we analyzed actions suggested to resolve these breaking changes introduced by transitive dependencies under the discussions on open-source platforms, and the frequently suggested action was to exclude the transitive dependency from the project configuration.

A paradigm shift is underway in Software Engineering, with AI systems such as LLMs playing an increasingly important role in boosting software development productivity. This trend is anticipated to persist. In the next years, we expect a growing symbiotic partnership between human software developers and AI. The Software Engineering research community cannot afford to overlook this trend; we must address the key research challenges posed by the integration of AI into the software development process. In this article, we present our vision of the future of software development in an AI-driven world and explore the key challenges that our research community should address to realize this vision.

User feedback on software usage is utilised by developers to improve their software. Software product forums are platforms rich in software-related user feedback, such as forum threads containing bug reports or requests for new features. However, previous studies have mainly focused on analysing user feedback from software product forums as individual sentences, which can lead to missing insights and a lack of understanding of the overall context of forum posts. To fill this gap in research, this work examines user feedback found in software product forum posts to investigate the differences between content classifications found in forum sentences and posts. We manually evaluated software product forum posts collected from two open-sourced software product forums and discovered five new types of user feedback that can only be identified when examining user feedback in the form of forum posts. Additionally, we examined the association between sentence classifications found within software product forums. Our results indicate that contextual information complimenting product improvement insights can be found in software product forums, with a confidence of 0.75 and 0.69 for the association between apparent bug and application usage sentences. This information can be used to reduce manual efforts required to chase up missing contextual information when attempting to understand or fix software issues. We also provide insights into the progression of posts in software product forums at the thread-level, and our progression flowchart can be used to summarise the sequence of events in software product forum threads. Our findings reveal the importance of looking at user feedback within software product forums in the format of forum posts to identify new insights on user feedback for software improvements. Editor’s note: Open Science material was validated by the Journal of Systems and Software Open Science Board.

Abstract Requirements Technical Debt (RTD) applies the Technical Debt (TD) metaphor to capture the consequences of sub-optimal decisions made concerning Requirements. Understanding the quantification of RTD is key to its management. To facilitate this understanding, we developed a conceptual model, the Requirements Technical Debt Quantification Model (RTDQM). Our work is grounded in the literature found via a systematic mapping study and informed by prior work modeling the quantification of software code-related TD types. The key finding is that although RTD is similar to code-related TD in many aspects, it also has its own components. RTD can be incurred regardless of the presence of code-related TD. Unlike code-related TD, RTD has a feedback loop involving the user. RTD can have a cascading impact on other development activities, such as design and implementation, apart from the extra costs and efforts incurred during requirements engineering activities; this is modeled by the RTD Interest constituents in our model. The model was used to compare and analyze existing quantification approaches. It helped identify what RTD quantification concepts are discussed in the existing approaches and what concepts are supported by metrics for their quantification. The model serves as a reference for practitioners to select existing or to develop new quantification approaches to support informed decision-making for RTD management.

To effectively manage Technical Debt (TD), we need reliable means to quantify it. We conducted a Systematic Mapping Study (SMS) where we identified 39 quantification approaches for Code, Design, and Architecture TD. We analyzed concepts and metrics discussed in these quantification approaches by classifying the quantification approaches based on a set of abstract TD Quantification (TDQ) concepts and their high-level themes, process/time, cost, benefit, probability, and priority, which we developed during our SMS. This helped identify gaps in the literature and to propose future research directions. Among the abstract TDQ concepts discussed in the different quantification approaches, TD item, TD remediation cost, TD interest, and Benefit of remediating TD were the most frequently discussed concepts. They were also supported by some form of measurement. However, some TDQ concepts were poorly examined, for example, the benefit of taking TD. It was evident that cost concepts were more frequently quantified among the approaches, while benefit concepts were not. Most of the approaches focused on remediating TD in retrospect rather than quantifying TD to strategically use it during software development. This raises the question of whether existing approaches reliably quantify TD and suggests the need to further explore TDQ.

Advances in Artificial Intelligence (AI), and in particular in Machine Learning (ML), are introducing profound changes to scholarly submissions across publication venues, affecting in particular the contributions that are being submitted to Software Engineering (SE) conferences and journals. In this context, it is not always clear whether manuscripts submitted to SE venues under the umbrella term SE for AI are indeed relevant to SE, in the sense that they explicitly contain contributions to the SE body of knowledge. This leads to recurring discussions on whether certain AI-related submissions are appropriate to SE venues, or should instead be submitted to other journals and conferences, including AI or ML-specific ones. In this editorial, we discuss the kinds of AI-related contributions that are a better fit-and a less good fit-for publication in the IEEE Transactions on Software Engineering.

Making sub-optimal design decisions during software development leads to the accumulation of Technical Debt (TD) in software projects. There are tools to identify TD Items in software code through static code analysis. However, quantifying TD to support decision-making on whether to keep taking on TD or if it is time to refactor TD is a difficult task, and proposed approaches for this still lack consensus. Prior work observed that TD Interest could be further decomposed into constituents ‘New Code Cost’ and ‘Rework Cost’, which gives an interesting direction of research to explore TD quantification in terms of these costs. Therefore, through our empirical study, we plan to explore the relationship between TD, New Code Cost and Rework Cost in Open-Source Software Projects. This paper reports on an initial motivating study, our plan for future work and implications for researchers.

Modern software applications rely heavily on the usage of libraries, which provide reusable functionality, to accelerate the development process. As libraries evolve and release new versions, the software systems that depend on those libraries (the clients) should update their dependencies to use these new versions as the new release could, for example, include critical fixes for security vulnerabilities. However, updating is not always a smooth process, as it can result in software failures in the clients if the new version includes breaking changes. Yet, there is little research on how these breaking changes impact the client projects in the wild. To identify if changes between two library versions cause breaking changes at the client end, we perform an empirical study on Java projects built using Maven. For the analysis, we used 18,415 Maven artifacts, which declared 142,355 direct dependencies, of which 71.60% were not up-to-date. We updated these dependencies and found that 11.58% of the dependency updates contain breaking changes that impact the client. We further analyzed these changes in the library which impact the client projects and examine if libraries have adhered to the semantic versioning scheme when introducing breaking changes in their releases. Our results show that changes in transitive dependencies were a major factor in introducing breaking changes during dependency updates and almost half of the detected client impacting breaking changes violate the semantic versioning scheme by introducing breaking changes in non-Major updates.

Requirements Technical Debt (RTD) is a research area where the Technical Debt (TD) metaphor is used to capture the consequences of sub-optimal decisions made concerning Requirements. Understanding the quantification of RTD is key to its management. To facilitate this understanding, we model the quantification of RTD. Our work is grounded in the literature found via a Systematic Mapping Study (SMS) and informed by prior work modeling the quantification of TD for software code-related TD types. This paper reports on the SMS and the development of our model, the RTD Quantification Model (RTDQM). The key observation from our work is that, although RTD is similar in most aspects to TD in software code, it also has its own components. Requirement artifacts have a feedback loop involving the User to precisely capture User Needs. RTD Interest (i.e., additional costs due to sub-optimal decisions concerning Requirements) can incur during both Requirements Engineering and Implementation activities. Furthermore, RTD can incur regardless of the presence of software code-related TD. Similar to benefits accrued by refactoring software code, rectifying RTD can also accrue benefits.

The source code of a Java-based software system is often structured into packages. When packages are large, they often carry maintainability quality issues. In the literature, there is a lack of empirical evidence on the specific maintainability issues that occur when packages become too large. Our study fills this gap by performing relationship analysis of package size with respect to internal maintainability characteristics (coupling, cohesion, and complexity) using package-level metrics collected from 111 open-source Java projects provided in Qualitas Corpus . Our results show significantly higher maintainability issues in large packages as indicated by the maintainability metrics. We also report strong relationships of package size with cohesion (represented by the number of connected components in a package) and complexity (measured by the number of internal relationships in a package). Based on these strong associations with package size, we show that these cohesion and complexity metrics can be used to identify large package refactoring opportunities. Furthermore, we also discuss why some maintainability metrics (e.g., coupling metrics) may not be useful for refactoring large packages. Editor’s note: Open Science material was validated by the Journal of Systems and Software Open Science Board .

User feedback is an important resource in modern software development, often containing requirements that help address user concerns and desires for a software product. The feedback in online channels is a recent focus for software engineering researchers, with multiple studies proposing automatic analysis tools. In this work, we investigate the product forums of two large open source software projects. Through a quantitative analysis, we show that forum feedback is often manually linked to related issue tracker entries and product documentation. By linking feedback to their existing documentation, development teams enhance their understanding of known issues, and direct their users to known solutions. We discuss how the links between forum, issue tracker, and product documentation form a requirements ecosystem that has not been identified in the previous literature. We apply state-of-the-art deep-learning to automatically match forum posts with related issue tracker entries. Our approach identifies requirement matches with a mean average precision of 58.9% and hit ratio of 82.2%. Additionally, we apply deep-learning using an innovative clustering technique, achieving promising performance when matching forum posts to related product documentation. We discuss the possible applications of these automated techniques to support the flow of requirements between forum, issue tracker, and product documentation.

Background: Software smells reflect the sub-optimal patterns in the software. In a similar way, community smells consider the sub-optimal patterns in the organizational and social structures of software teams. Related work performed empirical studies to identify the relationship between community smells and software smells at the architecture and code levels. However, how community smells relate with design smells is still unknown.

Feedback from software users is vital for engineering better software requirements. One tool for extracting requirements from online user feedback is clustering, where the most mentioned topics are found by grouping similar feedback together. For these topics to be understood, clusters have been summarized in previous work using characterizing phrases or sentences. This work evaluates which method of characterization (unigrams, bigrams, trigrams, or sentences) is most effective for understanding the semantic meaning of a whole cluster using feedback from multiple feedback sources. We evaluate multiple characterization methods to determine the ability of each method to create distinct, descriptive characterizations. We further evaluate the amount of requirements relevant characterizations created by each characterization method. We find that unigrams, bigrams, trigrams, and full sentences all perform similarly in distinguishing clusters from each other. However, we find that fewer and more expressive characterizations, such as full sentences, contain more requirements relevant information from a feedback cluster compared to more numerous but less expressive unigrams, meaning a sentence will better summarize the important requirement relevant information from a cluster. Our findings inform the future development of user feedback clustering tools, with different cluster characterization methods being quantitatively measured for the first time.

The software industry lacks gender diversity. Recent research has suggested that a toxic working culture is to blame. Studies have found that communications in software repositories directed towards women are more negative in general. In this study, we use a destructive criticism lens to examine gender differences in software code review feedback. Software code review is a practice where code is peer reviewed and negative feedback is often delivered. We explore differences in perceptions, frequency, and impact of destructive criticism across genders. We surveyed 93 software practitioners eliciting perceived reactions to hypothetical scenarios (or vignettes) where participants are asked to imagine receiving either constructive or destructive criticism. In addition, the survey collected general opinions on feedback obtained during software code review as well as the frequency that participants give and receive destructive criticism. We found that opinions on destructive criticism vary. Women perceive destructive criticism as less appropriate and are less motivated to continue working with the developer after receiving destructive criticism. Destructive criticism is fairly common with more than half of respondents having received nonspecific negative feedback and nearly a quarter having received inconsiderate negative feedback in the past year. Our results suggest that destructive criticism in code review could be a contributing factor to the lack of gender diversity observed in the software industry.

Scrum, the most popular agile method and project management framework, is widely reported to be used, adapted, misused, and abused in practice. However, not much is known about how Scrum actually works in practice, and critically, where, when, how and why it diverges from Scrum by the book. Through a Grounded Theory study involving semi-structured interviews of 45 participants from 30 companies and observations of five teams, we present our findings on how Scrum works in practice as compared to how it is presented in its formative books. We identify significant variations in these practices such as work breakdown, estimation, prioritization, assignment, the associated roles and artefacts, and discuss the underlying rationales driving the variations. Critically, we claim that not all variations are process misuse/abuse and propose a nuanced classification approach to understanding variations asstandard, necessary, contextual,andclear deviationsfor successful Scrum use and adaptation.

Self-assignment, where software developers choose their own tasks, is a common practice in agile teams. However, it is not known why developers select certain tasks. It is important for managers to be aware of these reasons to ensure sustainable self-assignment practices. We investigated developers’ preferences while they are choosing tasks for themselves. We collected data from 42 participants working in 25 different software companies. We applied Grounded Theory procedures to study and analyse factors for self-assigning tasks, which we grouped into three categories:task-based,developer-based, andopinion-based. We found that developers have individual preferences and not all factors are important to every developer. Managers share some common and varying perspectives around the identified factors. Most managers want developers to give higher priority to certain factors. Developers often need to balance between task priority and their own individual preferences, and managers facilitate this through a variety of strategies. Morerisk-aversemanagers encourage expertise-based self-assignment to ensure tasks are completed quickly. Managers who arerisk-balancingencourage developers to choose tasks that provide learning opportunities only when there is little risk of delays or reduced quality. Finally,growth-seekingmanagers regularly encourage team members to pick tasks outside their comfort zone to encourage growth opportunities. Our findings will help managers to understand what developers consider when self-assigning tasks and help them empower their teams to practice self-assignment in a sustainable manner.

The Repertory Grid Technique (RGT) has been applied within the software engineering domain to investigate a variety of topics. These include topics relating to architectural knowledge, team level tacit knowledge, and project success mechanisms. The technique is based on Personal Construct Theory (PCT) and is claimed to be suitable for gaining a deep understanding of peoples’ perspectives on a topic. The essence of RGT is a consideration of similarities and differences, for example, between different project instances. In this paper, we describe a case study in which we applied the technique with the aim of eliciting practitioners’ viewpoints on contextual factors for situated software practices. We interviewed twelve practitioners in three organisations. We found that the RGT approach was challenging to implement for several reasons. Participants had difficulty in choosing specific instances of a software practice, identifying similarities and differences tended to be problematic and causal pathways were not always easy to establish. Our contributions are the highlighting of the challenges that may occur when implementing this technique, an analysis of the issues encountered and some possible mitigation approaches. These may serve as support for SE researchers considering an RGT based study.

Background: Third party libraries used by a project (dependencies) can easily become outdated over time, a phenomenon called technical lag. Keeping dependencies up to date induces a significant overhead in terms of the resources (e.g, developer time), but necessary to maintain software quality. Aims: This study provides a large scale analysis of technical lag across the major package managers currently in use. Method: We conducted a mixed-methods study using open-source project data obtained from 14 package managers using the libraries.io dataset. Results: The majority of fixed version declarations, along with a significant number of flexible declarations, are outdated. Fixed declarations are not regularly updated, except in major updates, so they quickly lag. Despite the prevalence of breaking changes in updates, downgrading declarations to earlier versions are rare. Conclusions: Technical lag is prevalent but preventable across package managers - semantic versioning based declaration ranges would remove the majority of lag. Further tooling uptake is also recommended to minimise technical lag.

User feedback on mobile app stores, product forums, and on social media can contain product development insights. There has been a lot of recent research studying this feedback and developing methods to automatically extract requirement-related information. This feedback is generally considered to be the “voice of the users”; however, only a subset of software users provide online feedback. If the demographics of the online feedback givers are not representative of the user base, this introduces the possibility of developing software that does not meet the needs of all users. It is, therefore, important to understand who provides online feedback to ensure the needs of under-represented groups are not being missed.In this work, we directly survey 1040 software users about their feedback habits, software use, and demographic information. Their responses indicate that there are statistically significant differences in who gives feedback on each online channel, with respect to traditional demographics (gender, age, etc). We also identify key differences in what motivates software users to engage with each of the three channels. Our findings provide valuable context for requirements elicited from online feedback and show that considering information from all channels will provide a more comprehensive view of user needs.

Abstract Self-assignment, a self-directed method of task allocation in which teams and individuals assign and choose work for themselves, is considered one of the hallmark practices of empowered, self-organizing agile teams. Despite all the benefits it promises, agile software teams do not practice it as regularly as other agile practices such as iteration planning and daily stand-ups, indicating that it is likely not an easy and straighforward practice. There has been very little empirical research on self-assignment. This Grounded Theory study explores how self-assignment works in agile projects. We collected data through interviews with 42 participants representing 28 agile teams from 23 software companies and supplemented these interviews with observations. Based on rigorous application of Grounded Theory analysis procedures such as open, axial, and selective coding, we present a comprehensive grounded theory of making self-assignment work that explains the (a) context and (b) causal conditions that give rise to the need for self-assignment, (c) a set of facilitating conditions that mediate how self-assignment may be enabled, (d) a set of constraining conditions that mediate how self-assignment may be constrained and which are overcome by a set of (e) strategies applied by agile teams, which in turn result in (f) a set of consequences, all in an attempt to make the central phenomenon, self-assignment, work. The findings of this study will help agile practitioners and companies understand different aspects of self-assignment and practice it with confidence regularly as a valuable practice. Additionally, it will help teams already practicing self-assignment to apply strategies to overcome the challenges they face on an everyday basis.

Summary Forges are online collaborative platforms to support the development of distributed open source software. While once mighty keepers of open source vitality, software forges are rapidly becoming less and less relevant. For example, of the top 10 forges in 2011, only one survives today—SourceForge—the biggest of them all, but its numbers are dropping and its community is tenuous at best. Through mixed‐methods research, this article chronicles and analyze the software practice and experiences of the project's history—in particular its architectural and community/organizational decisions. We discovered a number of suboptimal social and architectural decisions and circumstances that, may have led to SourceForge's demise. In addition, we found evidence suggesting that the impact of such decisions could have been monitored, reduced, and possibly avoided altogether. The use of sociotechnical insights needs to become a basic set of design and software/organization monitoring principles that tell a cautionary tale on what to measure and what not to do in the context of large‐scale software forge and community design and management.

Software developers work on a variety of tasks ranging from the technical, e.g., writing code, to the social, e.g., participating in issue resolution discussions. The amount of work developers perform per week (their work-rate) also varies and depends on project needs and developer schedules. Prior work has shown that while moderate levels of increased technical work and multitasking lead to higher productivity, beyond a certain threshold, they can lead to lowered performance. Here, we study how increases in the short-term work-rate along both the technical and social dimensions are associated with changes in developers' work patterns, in particular communication sentiment, technical productivity, and social productivity. We surveyed active and prolific developers on GitHub to understand the causes and impacts of increased work-rates. Guided by the responses, we developed regression models to study how communication and committing patterns change with increased work-rates and fit those models to large-scale data gathered from traces left by thousands of GitHub developers. From our survey and models, we find that most developers do experience work-rate-increase-related changes in behavior. Most notably, our models show that there is a sizable effect when developers comment much more than their average: the negative sentiment in their comments increases, suggesting an increased level of stress. Our models also show that committing patterns do not change with increased commenting, and vice versa, suggesting that technical and social activities tend not to be multitasked.

Many modern software systems are built on top of existing packages (modules, components, libraries). The increasing number and complexity of dependencies has given rise to automated dependency management where package managers resolve symbolic dependencies against a central repository. When declaring dependencies, developers face various choices, such as whether or not to declare a fixed version or a range of versions. The former results in runtime behaviour that is easier to predict, whilst the latter enables flexibility in resolution that can, for example, prevent different versions of the same package being included and facilitates the automated deployment of bug fixes. We study the choices developers make across 17 different package managers, investigating over 70 million dependencies. This is complemented by a survey of 170 developers. We find that many package managers support - and the respective community adapts - flexible versioning practices. This does not always work: developers struggle to find the sweet spot between the predictability of fixed version dependencies, and the agility of flexible ones, and depending on their experience, adjust practices. We see some uptake of semantic versioning in some package managers, supported by tools. However, there is no evidence that projects switch to semantic versioning on a large scale. The results of this study can guide further research into better practices for automated dependency management, and aid the adaptation of semantic versioning.

The modern software landscape is highly competitive. Software companies need to quickly fix reported bugs and release requested new features, or they risk negative reviews and reduced market share. The amount of online user feedback prevents manual analysis. Past research has investigated automated requirement mining techniques on online platforms like App Stores and Twitter, but online product forums have not been studied. In this paper, we show that online product forums are a rich source of user feedback that may be used to elicit product requirements. The information contained in forum questions is different from what has been described in the related work on App Stores or Twitter. Users often provide detailed context to specific problems they encounter with a software product and other users respond with workarounds or to confirm the problem. Through the analysis of two large forums, we identify 18 different types of information (classifications) contained in forums that can be relevant to maintenance and evolution tasks. We show that a state-of-the-art App Store tool is unable to accurately classify forum data, which may be due to the differences in content. Thus, specific techniques are likely needed to mine requirements from product forums. In an exploratory study, we developed classifiers with forum specific features. Promising results are achieved for all classifiers with f-measure scores ranging from 70.3% to 89.8%.

Software startups are typically under extreme pressure to get to market quickly with limited resources and high uncertainty. This pressure and uncertainty is likely to cause startups to accumulate technical debt as they make decisions that are more focused on the short-term than the long-term health of the codebase. However, most research on technical debt has been focused on more mature software teams, who may have less pressure and, therefore, reason about technical debt very differently than software startups. In this study, we seek to understand the organizational factors that lead to and the benefits and challenges associated with the intentional accumulation of technical debt in software startups. We interviewed 16 professionals involved in seven different software startups. We find that the startup phase, the experience of the developers, software knowledge of the founders, and level of employee growth are some of the organizational factors that influence the intentional accumulation of technical debt. In addition, we find the software startups are typically driven to achieve a "good enough level," and this guides the amount of technical debt that they intentionally accumulate to balance the benefits of speed to market and reduced resources with the challenges of later addressing technical debt.

Software engineering practice has shifted from the development of products in closed environments toward more open and collaborative efforts. Software development has become significantly interdependent with other systems (e.g. services, apps) and typically takes place within large ecosystems of networked communities of stakeholder organizations. Such software ecosystems promise increased innovation power and support for consumer-oriented software services at scale and are characterized by a certain openness of their information flows. While such openness supports project and reputation management, it also brings requirements engineering-related challenges within the ecosystem, such as managing dynamic, emergent contributions from the ecosystem stakeholders, as well as collecting their input while protecting their IP. In this paper, we report from a study of requirements communication and management practices within IBM ® ’s Collaborative Lifecycle Management ® product development ecosystem. Our research used multiple methods for data collection, including interviews within several ecosystem actors, on-site participatory observation, and analysis of online project repositories. We chart and describe the flow of product requirements information through the ecosystem, how the open communication paradigm in software ecosystems provides opportunities for “just-in-time” RE—and which relies on emergent contributions from the ecosystem stakeholders—, as well as some of the challenges faced when traditional requirements engineering approaches are applied within such an ecosystem. More importantly, we discuss two tradeoffs brought about by the openness in software ecosystems: (1) allowing open, transparent communication while keeping intellectual property confidential within the ecosystem and (2) having the ability to act globally on a long-term strategy while empowering product teams to act locally to answer end users’ context-specific needs in a timely manner. A sufficient level of openness facilitates contributions of emergent stakeholders. The ability to include important emergent contributors early in requirements elicitation appears to be a crucial asset in software ecosystems.

There has been a significant interest in the estimation of time and effort in fixing defects among both software practitioners and researchers over the past two decades. However, most of the focus has been on prediction of time and effort in resolving bugs, without much regard to predicting time needed to complete high-level requirements, a critical step in release planning. In this paper, we describe a mixed-method empirical study on three large IBM projects in which we developed and evaluated a process of training a predictive model constituting a set of 29 features in nine categories in order to predict if a requirement will be completed within its planned iteration. We conducted feature engineering through iterative interviews with IBM practitioners as well as analysis of large development repositories of these three projects. Using machine learning techniques, we were able to make predictions on completion time of requirements at four different stages of their lifetime. Using our industrial partner's interest in high precision over recall, we then adopted a cost sensitive learning method and maximized precision of predictions (ranging from 0.8 to 0.97) while maintaining an acceptable recall. We also ranked the features based on their relative importance to the optimized predictive model. We show that although satisfying predictions can be made at early stages, performance of predictions improves over time by taking advantage of requirements' progress data. Furthermore, feature importance ranking results show that although importance of features are highly dependent on project and prediction stage, there are certain features (e.g. requirement creator, time remained to the end of iteration, time since last requirement summary change and number of times requirement has been replanned for a new iteration) that emerge as important across most projects and stages, implying future worthwhile research directions for both researchers and practitioners.

Task allocation is considered an important activity in software project management. However, the process of allocating tasks in agile software development teams has not received much attention in empirical research. Through a pilot study involving mixed open-ended and closed-ended interviews questions with 11 agile software practitioners working within a software development organization in India, we explain the process of task allocation as including three different mechanisms of workflow across teams: team-independent, team-dependent, and hybrid workflow; and five types of task allocation strategies: manager-driven, team-driven, individual-driven, manager-assisted and team-assisted. Knowing these workflow mechanisms and task allocation strategies will help software teams and project managers make more effective decisions around workflow and task allocation.

Software development has always inherently required multitasking: developers switch between coding, reviewing, testing, designing, and meeting with colleagues. The advent of software ecosystems like GitHub has enabled something new: the ability to easily switch between projects. Developers also have social incentives to contribute to many projects; prolific contributors gain social recognition and (eventually) economic rewards. Multitasking, however, comes at a cognitive cost: frequent context-switches can lead to distraction, sub-standard work, and even greater stress. In this paper, we gather ecosystem-level data on a group of programmers working on a large collection of projects. We develop models and methods for measuring the rate and breadth of a developers' context-switching behavior, and we study how context-switching affects their productivity. We also survey developers to understand the reasons for and perceptions of multitasking. We find that the most common reason for multitasking is interrelationships and dependencies between projects. Notably, we find that the rate of switching and breadth (number of projects) of a developer's work matter. Developers who work on many projects have higher productivity if they focus on few projects per day. Developers that switch projects too much during the course of a day have lower productivity as they work on more projects overall. Despite these findings, developers perceptions of the benefits of multitasking are varied.

Software has always been considered as malleable. Changes to software requirements are inevitable during the development process. Despite many software engineering advances over several decades, requirements changes are a source of project risk, particularly when businesses and technologies are evolving rapidly. Although effectively managing requirements changes is a critical aspect of software engineering, conceptions of requirements change in the literature and approaches to their management in practice still seem rudimentary. The overall goal of this study is to better understand the process of requirements change management. We present findings from an exploratory case study of requirements change management in a globally distributed setting. In this context we noted a contrast with the traditional models of requirements change. In theory, change control policies and formal processes are considered as a natural strategy to deal with requirements changes. Yet we observed that "informal requirements changes" (InfRc) were pervasive and unavoidable. Our results reveal an equally 'natural' informal change management process that is required to handle InfRc in parallel. We present a novel model of requirements change which, we argue, better represents the phenomenon and more realistically incorporates both the informal and formal types of change.

The goal of this one-day workshop is to bring together researchers interested in techniques and tools that leverage context information that accumulates around development activities. Developers continuously make use of context to make decisions, coordinate their work, understand the purpose behind their tasks, and understand how their tasks fit with the rest of the project. However, there is little research on defining what context is, how we can model it, and how we can use those models to better support software development at large. This workshop brings together scholars interested in identifying, gathering and modelling context information in software development, as well as discussing its applications.

Researchers are currently drawn to study projects hosted on GitHub due to its popularity, ease of obtaining data, and its distinctive built-in social features. GitHub has been found to create a transparent development environment, which together with a pull request-based workflow, provides a lightweight mechanism for committing, reviewing and managing code changes. These features impact how GitHub is used and the benefits it provides to teams' development and collaboration. While most of the evidence we have is from GitHub's use in open source software (OSS) projects, GitHub is also used in an increasing number of commercial projects. It is unknown how GitHub supports these projects given that GitHub's workflow model does not intuitively fit the commercial development way of working. In this paper, we report findings from an online survey and interviews with GitHub users on how GitHub is used for collaboration in commercial projects. We found that many commercial projects adopted practices that are more typical of OSS projects including reduced communication, more independent work, and self-organization. We discuss how GitHub's transparency and popular workflow can promote open collaboration, allowing organizations to increase code reuse and promote knowledge sharing across their teams.

We describe an experience in teaching global software engineering (GSE) using distributed Scrum augmented with industrial best practices. Our unique instructional technique had students work in both same-site and cross-site teams to contrast the two modes of working. The course was a collaboration between Aalto University, Finland and University of Victoria, Canada. Fifteen Canadian and eight Finnish students worked on a single large project, divided into four teams, working on interdependent user stories as negotiated with the industrial product owner located in Finland. Half way through the course, we changed the teams so each student worked in both a local and a distributed team. We studied student learning using a mixed-method approach including 14 post-course interviews, pre-course and Sprint questionnaires, observations, meeting recordings, and repository data from git and Flow dock, the primary communication tool. Our results show no significant differences between working in distributed vs. Non-distributed teams, suggesting that Scrum helps alleviate many GSE problems. Our post-course interviews and survey data allows us to explain this effect, we found that students over time learned to better self-select tasks with less inter-team dependencies, to communicate more, and to work better in teams.

Software projects are not developed in isolation. Recent research has shifted to studying software ecosystems, communities of projects that depend on each other and are developed together. However, identifying technical dependencies at the ecosystem level can be challenging. In this paper, we propose a new method, known as reference coupling, for detecting technical dependencies between projects. The method establishes dependencies through user-specified cross-references between projects. We use our method to identify ecosystems in GitHub-hosted projects, and we identify several characteristics of the identified ecosystems. We find that most ecosystems are centered around one project and are interconnected with other ecosystems. The predominant type of ecosystems are those that develop tools to support software development. We also found that the project owners' social behaviour aligns well with the technical dependencies within the ecosystem, but project contributors' social behaviour does not align with these dependencies. We conclude with a discussion on future research that is enabled by our reference coupling method.

When software developers fail to coordinate, build failures, duplication of work, schedule slips and software defects can result. However, developers are often unaware of when they need to coordinate, and existing methods and tools that help make developers aware of their coordination needs do not provide timely or efficient recommendations. We describe our techniques to identify timely and efficient coordination recommendations, which we developed and evaluated in a study of coordination needs in the Mylyn software project. We describe how data obtained from tools that capture developer actions within their Integrated Development Environment (IDE) as they occur can be used to timely identify coordination needs; we also describe how properties of tasks coupled with machine learning can focus coordination recommendations to those that are more critical to the developers to reduce information overload and provide more efficient recommendations. We motivate our techniques through developer interviews and report on our quantitative analysis of coordination needs in the Mylyn project. Our results suggest that by leveraging IDE logging facilities, properties of tasks and machine learning techniques awareness tools could make developers aware of critical coordination needs in a timely way. We conclude by discussing implications for software engineering research and tool design.

With over 10 million git repositories, GitHub is becoming one of the most important source of software artifacts on the Internet. Researchers are starting to mine the information stored in GitHub's event logs, trying to understand how its users employ the site to collaborate on software. However, so far there have been no studies describing the quality and properties of the data available from GitHub. We document the results of an empirical study aimed at understanding the characteristics of the repositories in GitHub and how users take advantage of GitHub's main features---namely commits, pull requests, and issues. Our results indicate that, while GitHub is a rich source of data on software development, mining GitHub for research purposes should take various potential perils into consideration. We show, for example, that the majority of the projects are personal and inactive; that GitHub is also being used for free storage and as a Web hosting service; and that almost 40% of all pull requests do not appear as merged, even though they were. We provide a set of recommendations for software engineering researchers on how to approach the data in GitHub.

Users on GitHub can watch repositories to receive notifications about project activity. This introduces a new type of passive project membership. In this paper, we investigate the behavior of watchers and their contribution to the projects they watch. We find that a subset of project watchers begin contributing to the project and those contributors account for a significant percentage of contributors on the project. As contributors, watchers are more confident and contribute over a longer period of time in a more varied way than other contributors. This is likely attributable to the knowledge gained through project notifications.

Several methods exist to detect the coordination needs within software teams. Evidence exists that developers’ awareness about coordination needs improves work performance. Distinguishing with certainty between critical and trivial coordination needs and identifying and prioritizing which specific tasks a pair of developers should coordinate about remains an open problem. We investigate what work dependencies should be considered when establishing coordination needs within a development team. We use our conceptualization of work dependencies named Proximity and leverage machine learning techniques to analyze what additional task properties are indicative of coordination needs. In a case study of the Mylyn project, we were able to identify from all potential coordination requirements a subset of 17% that are most critical. We define critical coordination requirements as those that can cause the most disruption to task duration when left unmanaged. These results imply that coordination awareness tools could be enhanced to make developers aware of only the coordination needs that can bring about the highest performance benefit.

We describe a method for determining coordination requirements in collaborative software development. Our method uses "live" data based on developer activity rather than relying on historical data such as source code commits which is prevalent in existing methods. We introduce proximity, a measure of the strength of the work dependencies that lead to coordination requirements among members of a software development organization. Our proximity measure relies on a tool which captures the interactions of a developer with her IDE. It quantifies the similarity between records of interactions of developers as they work on their assigned tasks. We describe an algorithm that measures proximity between pairs of tasks or pairs of developers. Through an empirical study on an open source project that routinely records environment interaction data, we show how proximity accurately determines coordination requirements. The proximity measure thus enables proactive detection of coordination requirements and makes possible real time intervention and coordination facilitation via management-, design- and team-related decisions.

Work dependencies often exist between the developers of a software project. These dependencies frequently result in a need for coordination between the involved developers. However, developers are not always aware of these Coordination Requirements. Current methods which detect the need to coordinate rely on information which is available only after development work has been completed. This does not enable developers to act on their coordination needs. I have investigated a more timely method to determine Coordination Requirements in a software development team as they emerge.

This research proposal focuses on finding evidence of implicit coordination in software, analyzing the effects of that implicit coordination, and creating tools to further exploit the use of the inherently cheaper coordination means.