SearcharxivSearch

arXiv subjects

Shaiful Chowdhury

Publications and source records attributed to Shaiful Chowdhury.

At least 19 recordsLinked to original sources

Think Harder and Don't Overlook Your Options: Revisiting Issue-Commit Linking with LLM-Assisted Retrieval

Linking issue reports to the commits that resolve them is essential for software traceability, maintenance, and evolution. Accurate issue-commit links help developers to understand system changes and the rationale behind them. While numerous automated techniques have been proposed, ranging from heuristic and feature-based approaches to modern deep learning and large language model approaches, our goal is to evaluate these techniques to determine which are most effective and efficient. In this study, we revisit several established issue-commit link recovery techniques, including BTLink, EasyLink, FRLink, RCLinker, and Hybrid-Linker, and assess their performance for reranking issue-commit links. We first evaluate different retrieval methods (BM25, BM25L, SBERT-Semantic Search, ANNOY, LSH, HNSW) for their ability to efficiently retrieve relevant commits, reducing the candidate set that must be considered by more computationally expensive models. Using the best retrieval methods, we then investigate the reranking effectiveness of different machine learning-based techniques, including traditional machine learning models, a cross-encoder, and large language models (ChatGPT, Qwen, Gemma, Llama), to refine the reranking of candidate commits and improve precision. Finally, we compare the effectiveness of these techniques. Our results show that dense retrieval methods outperform sparse retrieval approaches in identifying relevant commits and that combining dense and sparse retrieval can improve recall. Additionally, we find that traditional machine learning-based reranking techniques achieve higher performance than LLM-based approaches. Our results highlight that retrieval-based pipelines remain a practical and effective solution for large-scale issue-commit linking, and that simpler models should be carefully considered before adopting computationally expensive LLM-based approaches.

cs.SE

How Do Agentic AI Systems Address Performance Optimizations? A BERTopic-Based Analysis of Pull Requests

LLM-based software engineering is influencing modern software development. In addition to correctness, prior studies have also examined the performance of software artifacts generated by AI agents. However, it is unclear how exactly the agentic AI systems address performance concerns in practice. In this paper, we present an empirical study of performance-related pull requests generated by AI agents. Using LLM-assisted detection and BERTopic-based topic modeling, we identified 52 performance-related topics grouped into 10 higher-level categories. Our results show that AI agents apply performance optimizations across diverse layers of the software stack and that the type of optimization significantly affects pull request acceptance rates and review times. We also found that performance optimization by AI agents primarily occurs during the development phase, with less focus on the maintenance phase. Our findings provide empirical evidence that can support the evaluation and improvement of agentic AI systems with respect to their performance optimization behaviors and review outcomes.

cs.SE

How Do Agentic AI Systems Deal With Software Energy Concerns? A Pull Request-Based Study

As Software Engineering enters its new era (SE 3.0), AI coding agents increasingly automate software development workflows. However, it remains unclear how exactly these agents recognize and address software energy concerns-an issue growing in importance due to large-scale data centers, energy-hungry language models, and battery-constrained devices. In this paper, we examined the energy awareness of agent-authored pull requests (PRs) using a publicly available dataset. We identified 216 energy-explicit PRs and conducted a thematic analysis, deriving a taxonomy of energy-aware work. Our further analysis of the applied optimization techniques shows that most align with established research recommendations. Although building and running these agents is highly energy intensive, encouragingly, the results indicate that they exhibit energy awareness when generating software artifacts. However, optimization-related PRs are accepted less frequently than others, largely due to their negative impact on maintainability.

cs.SE

The Repeat Offenders: Characterizing and Predicting Extremely Bug-Prone Source Methods

Bug prediction has long been considered the "prince" of empirical software engineering research, and accordingly, a substantial body of work has focused on predicting bugs to enable early preventive actions. However, most existing studies operate at the class or file level, which practitioners have found to be of limited practical value. As a result, method-level bug prediction has gained increasing attention in recent years. Despite this shift, current method-level prediction models typically treat all buggy methods as equally fault-prone, regardless of whether a method has been associated with a bug once or repeatedly. We argue that methods involved in bugs multiple times-hereafter referred to as ExtremelyBuggy methods-are more harmful than methods that are buggy only once. In this study, we investigate the prevalence of ExtremelyBuggy methods, analyze their code quality metrics, and assess whether they can be predicted at the time of their introduction. In addition, we conduct a thematic analysis of 287 ExtremelyBuggy methods to gain deeper insights into their characteristics. Using a dataset of over 1.25 million methods extracted from 98 open-source Java projects, we find that only a small proportion of methods can be classified as ExtremelyBuggy, yet these methods account for a disproportionately large share of bugs within a project. Although we observe statistically significant differences between ExtremelyBuggy and other methods, ExtremelyBuggy methods remain difficult to predict at their inception. Nevertheless, our manual analysis reveals recurring characteristics among these methods. These findings can help practitioners avoid harmful patterns in practice and guide future research toward developing features and models that better capture the unique properties of such methods.

cs.SE

A First Look at the Self-Admitted Technical Debt in Test Code: Taxonomy and Detection

Self-admitted technical debt (SATD) refers to comments in which developers explicitly acknowledge code issues, workarounds, or suboptimal solutions. SATD is known to significantly increase software maintenance effort. While extensive research has examined SATD in source code, its presence and impact in test code have received no focused attention, leaving a significant gap in our understanding of how SATD manifests in testing contexts. This study, the first of its kind, investigates SATD in test code by manually analyzing 50,000 comments randomly sampled from 1.6 million comments across 1,000 open-source Java projects. From this sample, after manual analysis and filtering, we identified 615 SATD comments and classified them into 14 distinct categories, building a taxonomy of test code SATD. To investigate whether test code SATD can be detected automatically, we evaluated existing SATD detection tools, as well as both open-source and proprietary LLMs. Among the existing tools, MAT performed the best, albeit with moderate recall. To our surprise, both open-source and proprietary LLMs exhibited poor detection accuracy, primarily due to low precision. These results indicate that neither existing approaches nor current LLMs can reliably detect SATD in test code. Overall, this work provides the first large-scale analysis of SATD in test code, a nuanced understanding of its types, and the limitations of current SATD detection methods. Our findings lay the groundwork for future research on test code-specific SATD.

cs.SE

Applications and Challenges of Fairness APIs in Machine Learning Software

Machine Learning software systems are frequently used in our day-to-day lives. Some of these systems are used in various sensitive environments to make life-changing decisions. Therefore, it is crucial to ensure that these AI/ML systems do not make any discriminatory decisions for any specific groups or populations. In that vein, different bias detection and mitigation open-source software libraries (aka API libraries) are being developed and used. In this paper, we conduct a qualitative study to understand in what scenarios these open-source fairness APIs are used in the wild, how they are used, and what challenges the developers of these APIs face while developing and adopting these libraries. We have analyzed 204 GitHub repositories (from a list of 1885 candidate repositories) which used 13 APIs that are developed to address bias in ML software. We found that these APIs are used for two primary purposes (i.e., learning and solving real-world problems), targeting 17 unique use-cases. Our study suggests that developers are not well-versed in bias detection and mitigation; they face lots of troubleshooting issues, and frequently ask for opinions and resources. Our findings can be instrumental for future bias-related software engineering research, and for guiding educators in developing more state-of-the-art curricula.

cs.LG

HistoryFinder: Advancing Method-Level Source Code History Generation with Accurate Oracles and Enhanced Algorithm

Reconstructing a method's change history efficiently and accurately is critical for many software engineering tasks, including maintenance, refactoring, and comprehension. Despite the availability of method history generation tools such as CodeShovel and CodeTracker, existing evaluations of their effectiveness are limited by inaccuracies in the ground truth oracles used. In this study, we systematically construct two new oracles -- the corrected CodeShovel oracle and a newly developed HistoryFinder oracle -- by combining automated analysis with expert-guided manual validation. We also introduce HistoryFinder, a new method history generation tool designed to improve not only the accuracy and completeness of method change histories but also to offer competitive runtime performance. Through extensive evaluation across 400 methods from 40 open-source repositories, we show that HistoryFinder consistently outperforms CodeShovel, CodeTracker, IntelliJ, and Git-based baselines in terms of precision, recall, and F1 score. Moreover, HistoryFinder achieves competitive runtime performance, offering the lowest mean and median execution times among all the research-based tools. While Git-based tools exhibit the fastest runtimes, this efficiency comes at the cost of significantly lower precision and recall -- leaving HistoryFinder as the best overall choice when both accuracy and efficiency are important. To facilitate adoption, we provide a web interface, CLI, and Java library for flexible usage.

cs.SE

Moderately Mighty: To What Extent Can Internal Software Metrics Predict App Popularity at Launch?

Predicting a mobile app's popularity before its first release can provide developers with a strategic advantage in a competitive marketplace, yet it remains a challenging problem. This study explores the extent to which internal software metrics, measurable from source code before deployment, can predict an app's popularity (i.e., ratings and downloads per year) at inception. For our analysis, we constructed a rigorously filtered dataset of 446 open-source Java-based Android apps that are available on both F-Droid and Google Play Store. Using app source code from F-Droid, we extracted a wide array of internal metrics, including system-, class-, and method-level code metrics, code smells, and app metadata. Popularity-related information, including reviews and download counts, was collected from the Play Store. We evaluate regression and classification models across three feature sets: a minimal Size-only baseline, a domain-informed Handpicked set, and a Voting set derived via feature selection algorithms. Our results show that, for both app ratings and number of downloads, regression models perform poorly due to skewed rating distributions and a highly scattered range of download counts in our dataset. However, when reframed as a binary classification (Popular vs. Unpopular), performance improves significantly-the best model, a Multilayer Perceptron, achieves an F1-score of 0.72. We conclude that, although internal code metrics alone are insufficient for accurately predicting an app's future popularity, they do exhibit meaningful correlations with it. Thus, our findings challenge prior studies that have entirely dismissed internal metrics as valid indicators of software quality. Instead, our results align with research suggesting that internal code metrics can be valuable when evaluated within the appropriate context-specifically, we found them useful for classification tasks.

cs.SE

Understanding the Issue Types in Open Source Blockchain-based Software Projects with the Transformer-based BERTopic

Blockchain-based software systems are increasingly deployed across diverse domains, yet a systematic understanding of their development challenges remains limited. This paper presents a large-scale empirical study of 497,742 issues mined from 1,209 open-source blockchain projects hosted on GitHub. Employing BERTopic, a transformer-based topic modeling technique, we identify 49 distinct issue topics and organize them hierarchically into 11 major subcategories. Our analysis reveals that both general software development issues and blockchain-specific concerns are nearly equally represented, with Wallet Management and UI Enhancement emerging as the most prominent topics. We further examine the temporal evolution of issue categories and resolution times, finding that Wallet issues not only dominate in frequency but also exhibit the longest resolution time. Conversely, Mechanisms issues are resolved significantly faster. Issue frequency surged after 2016 with the rise of Ethereum and decentralized applications, but started declining after 2022. These findings enhance our understanding of blockchain software maintenance, informing the development of specialized tools and practices to improve robustness and maintainability.

cs.SE

LLM-Based Detection of Tangled Code Changes for Higher-Quality Method-Level Bug Datasets

Tangled code changes, commits that conflate unrelated modifications such as bug fixes, refactorings, and enhancements, introduce significant noise into bug datasets and adversely affect the performance of bug prediction models. Addressing this issue at a fine-grained, method-level granularity remains unexplored. This is critical to address, as recent bug prediction models, driven by practitioner demand, are increasingly focusing on finer granularity rather than traditional class- or file-level predictions. This study investigates the utility of Large Language Models (LLMs) for detecting tangled code changes by leveraging both commit messages and method-level code diffs. We formulate the problem as a binary classification task and evaluate multiple prompting strategies, including zero-shot, few-shot, and chain-of-thought prompting, using state-of-the-art proprietary LLMs such as GPT-5 and Gemini-2.0-Flash, and open-source models such as GPT-OSS-120B and CodeBERT. Our results demonstrate that combining commit messages with code diffs significantly enhances model performance, with the combined few-shot and chain-of-thought prompting achieving an F1-score of 0.883. Additionally, we explore machine learning models trained on LLM-generated embeddings, where a multi-layer perceptron classifier achieves superior performance (F1-score: 0.906, MCC: 0.807). Applying our approach to 49 open-source projects improves the distributional separability of code metrics between buggy and non-buggy methods, demonstrating the promise of LLMs for method-level commit untangling and potentially contributing to improving the accuracy of future bug prediction models.

cs.SE

Exploring Challenges in Test Mocking: Developer Questions and Insights from StackOverflow

Mocking is a common unit testing technique that is used to simplify tests, reduce flakiness, and improve coverage by replacing real dependencies with simplified implementations. Despite its widespread use in Open Source Software projects, there is limited understanding of how and why developers use mocks and the challenges they face. In this collaborative study, we have analyzed 25,302 questions related to Mocking on STACKOVERFLOW to identify the challenges faced by developers. We have used Latent Dirichlet Allocation for topic modeling, identified 30 key topics, and grouped the topics into five key categories. Consequently, we analyzed the annual and relative probabilities of each category to understand the evolution of mocking-related discussions. Trend analysis reveals that category like Advanced Programming peaked between 2009 and 2012 but have since declined, while categories such as Mocking Techniques and External Services have remained consistently dominant, highlighting evolving developer priorities and ongoing technical challenges. Our findings also show an inverse relationship between a topic's popularity and its difficulty. Popular topics like Framework Selection tend to have lower difficulty and faster resolution times, while complex topics like HTTP Requests and Responses are more likely to remain unanswered and take longer to resolve. A classification of questions into How, Why, What, and Other revealed that over 70% are How questions, particularly in practical domains like file access and APIs, indicating a strong need for implementation guidance. Why questions are more prevalent in error-handling contexts, reflecting conceptual challenges in debugging, while What questions are rare and mostly tied to theoretical discussions. These insights offer valuable guidance for improving developer support, tooling, and educational content in the context of mocking and unit testing.

cs.SE

Dependency Dilemmas: A Comparative Study of Independent and Dependent Artifacts in Maven Central Ecosystem

The Maven Central ecosystem forms the backbone of Java dependency management, hosting artifacts that vary significantly in their adoption, security, and ecosystem roles. Artifact reuse is fundamental in software development, with ecosystems like Maven Central facilitating this process. However, prior studies predominantly analyzed popular artifacts with numerous dependencies, leaving those without incoming dependencies (independent artifacts) unexplored. In this study, we analyzed 658,078 artifacts, of which 635,003 had at least one release. Among these, 93,101 artifacts (15.4%) were identified as independent (in-degree = 0), while the rest were classified as dependent. We looked at the impact of separate artifacts using PageRank and out-degree centrality and discovered that they were very important to the ecosystem. Further analysis across 18 different metrics revealed several advantages and comparability of independent artifacts with dependent artifacts: comparable popularity (25.58 vs. 7.30), fewer vulnerabilities (60 CVEs vs. 179 CVEs), and zero propagated vulnerabilities. Based on these results, it seems that independent artifacts make a big difference in the ecosystem and give developers a safe, self-contained alternative to traditional dependencies. These findings suggest that independent artifacts might be a beneficial choice for dependencies but have some maintainability issues. Therefore, developers should carefully incorporate independent artifacts into their projects, and artifact maintainers should prioritize this group of artifacts to mitigate the risk of transitive vulnerability propagation and improve software sustainability.

cs.SE

Evidence is All We Need: Do Self-Admitted Technical Debts Impact Method-Level Maintenance?

Self-Admitted Technical Debt (SATD) refers to the phenomenon where developers explicitly acknowledge technical debt through comments in the source code. While considerable research has focused on detecting and addressing SATD, its true impact on software maintenance remains underexplored. The few studies that have examined this critical aspect have not provided concrete evidence linking SATD to negative effects on software maintenance. These studies, however, focused only on file- or class-level code granularity. This paper aims to empirically investigate the influence of SATD on various facets of software maintenance at the method level. We assess SATD's effects on code quality, bug susceptibility, change frequency, and the time practitioners typically take to resolve SATD. By analyzing a dataset of 774,051 methods from 49 open-source projects, we discovered that methods containing SATD are not only larger and more complex but also exhibit lower readability and a higher tendency for bugs and changes. We also found that SATD often remains unresolved for extended periods, adversely affecting code quality and maintainability. Our results provide empirical evidence highlighting the necessity of early identification, resource allocation, and proactive management of SATD to mitigate its long-term impacts on software quality and maintenance costs.

cs.SE

Evaluating the Effectiveness and Efficiency of Demonstration Retrievers in RAG for Coding Tasks

Retrieval-Augmented Generation (RAG) enhances Large Language Models (LLMs) by integrating external knowledge bases, achieving state-of-the-art results in various coding tasks. The core of RAG is retrieving demonstration examples, which is essential to balance effectiveness (generation quality) and efficiency (retrieval time) for optimal performance. However, the high-dimensional nature of code representations and large knowledge bases often create efficiency bottlenecks, which are overlooked in previous research. This paper systematically evaluates the efficiency-effectiveness trade-off of retrievers across three coding tasks: Program Synthesis, Commit Message Generation, and Assertion Generation. We examined six retrievers: two sparse (BM25 and BM25L) and four dense retrievers, including one exhaustive dense retriever (SBERT's Semantic Search) and three approximate dense retrievers (ANNOY, LSH, and HNSW). Our findings show that while BM25 excels in effectiveness, it suffers in efficiency as the knowledge base grows beyond 1000 entries. In large-scale retrieval, efficiency differences become more pronounced, with approximate dense retrievers offering the greatest gains. For instance, in Commit Generation task, HNSW achieves a 44x speed up, while only with a 1.74% drop in RougeL compared with BM25. Our results also show that increasing the number of demonstrations in the prompt doesn't always improve the effectiveness and can increase latency and lead to incorrect outputs. Our findings provide valuable insights for practitioners aiming to build efficient and effective RAG systems for coding tasks.

cs.SE

Robotics Meets Software Engineering: A First Look at the Robotics Discussions on Stackoverflow

Robots can greatly enhance human capabilities, yet their development presents a range of challenges. This collaborative study, conducted by a team of software engineering and robotics researchers, seeks to identify the challenges encountered by robot developers by analyzing questions posted on StackOverflow. We created a filtered dataset of 500 robotics-related questions and examined their characteristics, comparing them with randomly selected questions from the platform. Our findings indicate that the small size of the robotics community limits the visibility of these questions, resulting in fewer responses. While the number of robotics questions has been steadily increasing, they remain less popular than the average question and answer on StackOverflow. This underscores the importance of research that focuses on the challenges faced by robotics practitioners. Consequently, we conducted a thematic analysis of the 500 robotics questions to uncover common inquiry patterns. We identified 11 major themes, with questions about robot movement being the most frequent. Our analysis of yearly trends revealed that certain themes, such as Specifications, were prominent from 2009 to 2014 but have since diminished in relevance. In contrast, themes like Moving, Actuator, and Remote have consistently dominated discussions over the years. These findings suggest that challenges in robotics may vary over time. Notably, the majority of robotics questions are framed as How questions, rather than Why or What questions, revealing the lack of enough resources for the practitioners. These insights can help guide researchers and educators in developing effective and timely educational materials for robotics practitioners.

cs.SE

A Systematic Mapping Study of Crowd Knowledge Enhanced Software Engineering Research Using Stack Overflow

Developers continuously interact in crowd-sourced community-based question-answer (Q&A) sites. Reportedly, 30% of all software professionals visit the most popular Q&A site StackOverflow (SO) every day. Software engineering (SE) research studies are also increasingly using SO data. To find out the trend, implication, impact, and future research potential utilizing SO data, a systematic mapping study needs to be conducted. Following a rigorous reproducible mapping study approach, from 18 reputed SE journals and conferences, we collected 384 SO-based research articles and categorized them into 10 facets (i.e., themes). We found that SO contributes to 85% of SE research compared with popular Q&A sites such as Quora, and Reddit. We found that 18 SE domains directly benefited from SO data whereas Recommender Systems, and API Design and Evolution domains use SO data the most (15% and 16% of all SO-based research studies, respectively). API Design and Evolution, and Machine Learning with/for SE domains have consistent upward publication. Deep Learning Bug Analysis and Code Cloning research areas have the highest potential research impact recently. With the insights, recommendations, and facet-based categorized paper list from this mapping study, SE researchers can find potential research areas according to their interest to utilize large-scale SO data.

cs.SE

The Good, the Bad, and the Monstrous: Predicting Highly Change-Prone Source Code Methods at Their Inception

The cost of software maintenance often surpasses the initial development expenses, making it a significant concern for the software industry. A key strategy for alleviating future maintenance burdens is the early prediction and identification of change-prone code components, which allows for timely optimizations. While prior research has largely concentrated on predicting change-prone files and classes, an approach less favored by practitioners, this paper shifts focus to predicting highly change-prone methods, aligning with the preferences of both practitioners and researchers. We analyzed 774,051 source code methods from 49 prominent open-source Java projects. Our findings reveal that approximately 80% of changes are concentrated in just 20% of the methods, demonstrating the Pareto 80/20 principle. Moreover, this subset of methods is responsible for the majority of the identified bugs in these projects. After establishing their critical role in mitigating software maintenance costs, our study shows that machine learning models can effectively identify these highly change-prone methods from their inception. Additionally, we conducted a thorough manual analysis to uncover common patterns (or concepts) among the more difficult-to-predict methods. These insights can help future research develop new features and enhance prediction accuracy.

cs.SE

Versioned Analysis of Software Quality Indicators and Self-admitted Technical Debt in Ethereum Smart Contracts with Ethstractor

The rise of decentralized applications (dApps) has made smart contracts imperative components of blockchain technology. As many smart contracts process financial transactions, their security is paramount. Moreover, the immutability of blockchains makes vulnerabilities in smart contracts particularly challenging because it requires deploying a new version of the contract at a different address, incurring substantial fees paid in Ether. This paper proposes Ethstractor, the first smart contract collection tool for gathering a dataset of versioned smart contracts. The collected dataset is then used to evaluate the reliability of code metrics as indicators of vulnerabilities in smart contracts. Our findings indicate that code metrics are ineffective in signalling the presence of vulnerabilities. Furthermore, we investigate whether vulnerabilities in newer versions of smart contracts are mitigated and identify that the number of vulnerabilities remains consistent over time. Finally, we examine the removal of self-admitted technical debt in contracts and uncover that most of the introduced debt has never been subsequently removed.

cs.DC