arXiv subjects

Zadia Codabux

Publications and source records attributed to Zadia Codabux.

14 recordsLinked to original sources

arXiv2026

Understanding Undesirable Attributes of Requirements Engineers: Insights from Practitioners

Context. The characteristics of software professionals have been widely investigated in the literature. However, limited attention has been given to undesirable attributes in Requirements Engineering, despite the strong dependence of this activity on stakeholder interaction and collaboration. Objectives. This study investigates the undesirable attributes of requirements engineers' hat may hinder collaboration and project success. Method. We surveyed software practitioners to identify these attributes and conducted interviews to gather supporting evidence. Results. Seventeen undesirable attributes were identified, grouped into four categories (communication issues, lack of domain knowledge, personality, and lack of technical knowledge), and organized into conceptual maps. Conclusion. The maps help requirements engineers reflect on and improve their professional practice by recognizing traits that may hinder collaboration and project outcomes.

cs.SE↗

arXiv2026

Breaking the Alphabet: Rethinking File Ordering in Code Review

Effective code review is central to maintaining software quality, yet there is limited research about how the ordering of changed files in Pull Requests (PRs) influences review effectiveness. Most popular code review tools default to alphabetical ordering, favoring predictability over contextual relevance. While prior studies examined how file position shapes reviewer attention, it remains unclear how such ordering influences cognitive load and perceived review thoroughness. This study presents the first large-scale survey of 1,355 professional developers across 182 widely used open-source projects to investigate how file ordering impacts review behavior, comprehension, and perceived effectiveness. Our mixed-methods analysis reveals that only 10.2% of reviewers consider alphabetical ordering optimal, underscoring a cognitive misalignment in their interpretation of code changes. Although some developers appreciate its predictability, more than half (57.6%) report that it increases context switching, disrupts logical reasoning, and contributes to review fatigue, and 63.9% expressed concern that the default ordering may cause them to miss bugs. We further identify key challenges in multi-file reviews and elicit developers' expectations for improved tooling, including dependency-aware grouping and customizable file ordering (requested by 66% of reviewers). These findings highlight the need for reviewer-centric interface designs that better align tool behavior with human cognition.

cs.SE↗

arXiv2026

Security Concerns in Generative AI Coding Assistants: Insights from Online Discussions on GitHub Copilot

Generative Artificial Intelligence (GenAI) has become a central component of many development tools (e.g., GitHub Copilot) that support software practitioners across multiple programming tasks, including code completion, documentation, and bug detection. However, current research has identified significant limitations and open issues in GenAI, including reliability, non-determinism, bias, and copyright infringement. While prior work has primarily focused on assessing the technical performance of these technologies for code generation, less attention has been paid to emerging concerns of software developers, particularly in the security realm. OBJECTIVE: This work explores security concerns regarding the use of GenAI-based coding assistants by analyzing challenges voiced by developers and software enthusiasts in public online forums. METHOD: We retrieved posts, comments, and discussion threads addressing security issues in GitHub Copilot from three popular platforms, namely Stack Overflow, Reddit, and Hacker News. These discussions were clustered using BERTopic and then synthesized using thematic analysis to identify distinct categories of security concerns. RESULTS: Four major concern areas were identified, including potential data leakage, code licensing, adversarial attacks (e.g., prompt injection), and insecure code suggestions, underscoring critical reflections on the limitations and trade-offs of GenAI in software engineering. IMPLICATIONS: Our findings contribute to a broader understanding of how developers perceive and engage with GenAI-based coding assistants, while highlighting key areas for improving their built-in security features.

cs.SE↗

arXiv2026

Investigating Technical Debt Types, Issues, and Solutions in Serverless Computing

Serverless computing is a cloud execution model where developers run code, and the server management is handled by the cloud provider. Serverless computing is increasingly gaining popularity as more systems adopt it to enhance scalability and reduce operational costs. While it has numerous benefits, it also embodies unique challenges inherent to serverless computing. One such challenge is Technical Debt (TD), which is exacerbated by the complexities of the serverless paradigm. While prior work has investigated the activities and bad practices that lead to TD in serverless computing, there remains a gap in understanding how TD manifests, the challenges it poses, and the solutions proposed to address TD issues in serverless systems. This study aims to investigate TD in the serverless context using Stack Overflow (SO) as a knowledge base. We collected 78,867 serverless questions on SO and labeled them as TD or non-TD using deep learning. Moreover, we conducted an in-depth analysis to identify types of TD in serverless settings, associated issues, and proposed solutions. We found that 37% of the serverless questions on SO are TD-related. We also identified six serverless-specific issues. Our research highlights the need for tools that can effectively detect TD in serverless applications.

cs.SE↗

arXiv2025

Manifesto from Dagstuhl Perspectives Workshop 24452 -- Reframing Technical Debt

This is the Dagstuhl Perspectives Workshop 24452 manifesto on Reframing Technical Debt. The manifesto begins with a one-page summary of Values, Beliefs, and Principles. It then elaborates on each Value, Belief, and Principle to explain their rationale and clarify their meaning. Subsequently, the paper describes the current landscape of Technical Debt Management methods and tools and explains why the current practice is inadequate and where current research falls short. The current landscape is organized into five major topics: Technical Debt as Value-Creation, Tooling, Data Collection, the role of Architecture, and Socio-Technical Aspects. Finally, the paper outlines a roadmap to realize the stated principles, with concrete milestones to be addressed by researchers, software practitioners, and tool vendors. The manifesto is signed by the workshop participants.

cs.SE↗

arXiv2025

Racing Against the Clock: Exploring the Impact of Scheduled Deadlines on Technical Debt

Background: Technical Debt (TD) describes suboptimal software development practices with long-term consequences, such as defects and vulnerabilities. Deadlines are a leading cause of the emergence of TD in software systems. While multiple aspects of TD have been studied, the empirical research findings on the impact of deadlines are still inconclusive. Aims: This study investigates the impact of scheduled deadlines on TD. It analyzes how scheduled deadlines affect code quality, commit activities, and issues in issue-tracking systems. Method: We analyzed eight Open Source Software (OSS) projects with regular release schedules using SonarQube. We analyzed 12.3k commits and 371 releases across these eight OSS projects. The study combined quantitative metrics with qualitative analyses to comprehensively understand TD accumulation under scheduled deadlines. Results: Our findings indicated that some projects had a clear increase in TD as deadlines approached (with above 50% of releases having increasing TD accumulation as deadlines approached), while others managed to maintain roughly the same amount of TD. Analysis of commit activities and issue tracking revealed that deadline proximity could lead to increased commit frequency and bug-related issue creation. Conclusions: Our study highlights that, in some cases, impending deadlines have a clear impact on TD. The findings pinpoint the need to mitigate last-minute coding rushes and the risks associated with deadline-driven TD accumulation.

cs.SE↗

arXiv2025

Teaching Mining Software Repositories

Mining Software Repositories (MSR) has become a popular research area recently. MSR analyzes different sources of data, such as version control systems, code repositories, defect tracking systems, archived communication, deployment logs, and so on, to uncover interesting and actionable insights from the data for improved software development, maintenance, and evolution. This chapter provides an overview of MSR and how to conduct an MSR study, including setting up a study, formulating research goals and questions, identifying repositories, extracting and cleaning the data, performing data analysis and synthesis, and discussing MSR study limitations. Furthermore, the chapter discusses MSR as part of a mixed method study, how to mine data ethically, and gives an overview of recent trends in MSR as well as reflects on the future. As a teaching aid, the chapter provides tips for educators, exercises for students at all levels, and a list of repositories that can be used as a starting point for an MSR study.

cs.SE↗

arXiv2024

Attributes of a Great Requirements Engineer

[Context and Motivation] Several studies have investigated attributes of great software practitioners. However, the investigation of such attributes is still missing in Requirements Engineering (RE). The current knowledge on attributes of great software practitioners might not be easily translated to the context of RE because its activities are, usually, less technical and more human-centered than other software engineering activities. [Question/Problem] This work aims to investigate which are the attributes of great requirements engineers, the relationship between them, and strategies that can be employed to obtain these attributes. We follow a method composed of a survey with 18 practitioners and follow up interviews with 11 of them. [Principal Ideas/Results] Investigative ability in talking to stakeholders, judicious, and understand the business are the most commonly mentioned attributes amongst the set of 22 attributes identified, which were grouped into four categories. We also found 38 strategies to improve RE skills. Examples are training, talking to all stakeholders, and acquiring domain knowledge. [Contribution] The attributes, their categories, and relationships are organized into a map. The relations between attributes and strategies are represented in a Sankey diagram. Software practitioners can use our findings to improve their understanding about the role and responsibilities of requirements engineers.

cs.SE↗

arXiv2024

Are Large Language Models a Threat to Programming Platforms? An Exploratory Study

Competitive programming platforms like LeetCode, Codeforces, and HackerRank evaluate programming skills, often used by recruiters for screening. With the rise of advanced Large Language Models (LLMs) such as ChatGPT, Gemini, and Meta AI, their problem-solving ability on these platforms needs assessment. This study explores LLMs' ability to tackle diverse programming challenges across platforms with varying difficulty, offering insights into their real-time and offline performance and comparing them with human programmers. We tested 98 problems from LeetCode, 126 from Codeforces, covering 15 categories. Nine online contests from Codeforces and LeetCode were conducted, along with two certification tests on HackerRank, to assess real-time performance. Prompts and feedback mechanisms were used to guide LLMs, and correlations were explored across different scenarios. LLMs, like ChatGPT (71.43% success on LeetCode), excelled in LeetCode and HackerRank certifications but struggled in virtual contests, particularly on Codeforces. They performed better than users in LeetCode archives, excelling in time and memory efficiency but underperforming in harder Codeforces contests. While not immediately threatening, LLMs performance on these platforms is concerning, and future improvements will need addressing.

cs.SE↗

arXiv2023

Investigating Software Developers' Challenges for Android Permissions in Stack Overflow

The Android permission system is a set of controls to regulate access to sensitive data and platform resources (e.g., camera). The fast evolving nature of Android permissions, coupled with inadequate documentation, results in numerous challenges for third-party developers. This study investigates the permission-related challenges developers face and the solutions provided to resolve them on the crowdsourcing platform Stack Overflow. We conducted qualitative and quantitative analyses on 3,327 permission-related questions and 3,271 corresponding answers. Our study found that most questions are related to non-evolving SDK permissions that remain constant across various Android versions, which emphasizes the lack of documentation. We classify developers' challenges into several categories: Documentation-Related, Problems with Dependencies, Debugging, Conceptual Understanding, and Implementation Issues. We further divided these categories into 12 subcategories, nine sub-subcategories, and nine sub-sub-subcategories. Our analysis shows that developers infrequently identify the restriction type or protection level of permissions, and when they do, their descriptions often contradict Google's official documentation. Our study indicates the need for clear, consistent documentation to guide the use of permissions and reduce developer misunderstanding leading to potential misuse of Android permission. These insights from this study can inform strategies and guidelines for permission issues. Future studies should explore the effectiveness of Stack Overflow solutions to form best practices and develop tools to address these problems.

cs.SE↗

arXiv2023

Exploring Technical Debt in Security Questions on Stack Overflow

Background: Software security is crucial to ensure that the users are protected from undesirable consequences such as malware attacks which can result in loss of data and, subsequently, financial loss. Technical Debt (TD) is a metaphor incurred by suboptimal decisions resulting in long-term consequences such as increased defects and vulnerabilities if not managed. Although previous studies have studied the relationship between security and TD, examining their intersection in developers' discussion on Stack Overflow (SO) is still unexplored. Aims: This study investigates the characteristics of security-related TD questions on SO. More specifically, we explore the prevalence of TD in security-related queries, identify the security tags most prone to TD, and investigate which user groups are more aware of TD. Method: We mined 117,233 security-related questions on SO and used a deep-learning approach to identify 45,078 security-related TD questions. Subsequently, we conducted quantitative and qualitative analyses of the collected security-related TD questions, including sentiment analysis. Results: Our analysis revealed that 38% of the security questions on SO are security-related TD questions. The most recurrent tags among the security-related TD questions emerged as "security" and "encryption." The latter typically have a neutral sentiment, are lengthier, and are posed by users with higher reputation scores. Conclusions: Our findings reveal that developers implicitly discuss TD, suggesting developers have a potential knowledge gap regarding the TD metaphor in the security domain. Moreover, we identified the most common security topics mentioned in TD-related posts, providing valuable insights for developers and researchers to assist developers in prioritizing security concerns in order to minimize TD and enhance software security.

cs.SE↗

arXiv2021

Technical Debt in the Peer-Review Documentation of R Packages: a rOpenSci Case Study

Context: Technical Debt is a metaphor used to describe code that is "not quite right." Although TD studies have gained momentum, TD has yet to be studied as thoroughly in non-Object-Oriented (OO) or scientific software such as R. R is a multi-paradigm programming language, whose popularity in data science and statistical applications has amplified in recent years. Due to R's inherent ability to expand through user-contributed packages, several community-led organizations were created to organize and peer-review packages in a concerted effort to increase their quality. Nonetheless, it is well-known that most R users do not have a technical programming background, being from multiple disciplines. Objective: The goal of this study is to investigate TD in the peer-review documentation of R packages led by rOpenSci. Method: We collected over 5000 comments from 157 packages that had been reviewed and approved to be published at rOpenSci. We manually analyzed a sample dataset of these comments posted by package authors, editors of rOpenSci, and reviewers during the review process to investigate the TD types present in these reviews. Results: The findings of our study include (i) a taxonomy of TD derived from our analysis of the peer-reviews (ii) documentation debt as being the most prevalent type of debt (iii) different user roles are concerned with different types of TD. For instance, reviewers tend to report some TD types more than other roles, and the TD types they report are different from those reported by the authors of a package. Conclusion: TD analysis in scientific software or peer-review is almost non-existent. Our study is a pioneer but within the context of R packages. However, our findings can serve as a starting point for replication studies, given our public datasets, to perform similar analyses in other scientific software or to investigate the rationale behind our findings.

cs.SE↗

arXiv2020

Examining the Relationship of Code and Architectural Smells with Software Vulnerabilities

Context: Security is vital to software developed for commercial or personal use. Although more organizations are realizing the importance of applying secure coding practices, in many of them, security concerns are not known or addressed until a security failure occurs. The root cause of security failures is vulnerable code. While metrics have been used to predict software vulnerabilities, we explore the relationship between code and architectural smells with security weaknesses. As smells are surface indicators of a deeper problem in software, determining the relationship between smells and software vulnerabilities can play a significant role in vulnerability prediction models. Objective: This study explores the relationship between smells and software vulnerabilities to identify the smells. Method: We extracted the class, method, file, and package level smells for three systems: Apache Tomcat, Apache CXF, and Android. We then compared their occurrences in the vulnerable classes which were reported to contain vulnerable code and in the neutral classes (non-vulnerable classes where no vulnerability had yet been reported). Results: We found that a vulnerable class is more likely to have certain smells compared to a non-vulnerable class. God Class, Complex Class, Large Class, Data Class, Feature Envy, Brain Class have a statistically significant relationship with software vulnerabilities. We found no significant relationship between architectural smells and software vulnerabilities. Conclusion: We can conclude that for all the systems examined, there is a statistically significant correlation between software vulnerabilities and some smells.

cs.SE↗

arXiv2020

Profiling Developers Through the Lens of Technical Debt

Context: Technical Debt needs to be managed to avoid disastrous consequences, and investigating developers' habits concerning technical debt management is invaluable information in software development. Objective: This study aims to characterize how developers manage technical debt based on the code smells they induce and the refactorings they apply. Method: We mined a publicly-available Technical Debt dataset for Git commit information, code smells, coding violations, and refactoring activities for each developer of a selected project. Results: By combining this information, we profile developers to recognize prolific coders, highlight activities that discriminate among developer roles (reviewer, lead, architect), and estimate coding maturity and technical debt tolerance.

cs.SE↗