Background: Software development relies on collaborative problem-solving. Understanding previously addressed problems in software is crucial for developers to identify and repurpose functionalities for new problem-solving contexts. Objective: We explore the barriers programmers encounter during code repurposing and investigate how access to historical context about the original developer's goals may affect this process. Method: We present an exploratory study of 16 programmers who completed two code repurposing tasks in different code bases. Participants completed these tasks both with and without access to the historical information of the original developer's goals. We explore how programmers use analogical reasoning to identify and apply existing software artifacts to new goals. Results: We show that programmers often failed to notice analogies, made false analogies, and underestimated the value of reuse. Even when useful analogies were made, programmers struggled to find the relevant code. We also describe the patterns of how participants utilized code histories. Conclusion: We highlight the barriers programmers face in noticing and applying analogies during code reuse. We suggest design recommendations for future tools to allow lightweight evaluation of code to help programmers identify reuse opportunities.
more »
« less
Exploring the impacts of semi-automated storytelling on programmers' comprehension of software histories
Software developers have difficulty understanding the rationale and intent behind original developers' design decisions. Code histories aim to provide richer contexts for code changes over time, but can introduce a large amount of information to the already cognitively demanding task of code comprehension. Storytelling has shown benefits in communicating complex, time-dependent information, yet programmers are reluctant to write stories for their code changes. We explored the utility of narratives made by generative AI. We conducted a within-subjects study comparing the performance of 16 programmers when recalling code history information from a list-view format versus a comparable AI-generated narrative format. Our study found that when using the story-view, participants were 16\% more successful at recalling code history information, and had 30\% less error when assessing the correctness of their responses. We did not find any significant differences in programmer's perceived mental effort or their attitudes towards reuse when using narrative code stories.
more »
« less
- Award ID(s):
- 2128128
- PAR ID:
- 10545450
- Publisher / Repository:
- IEEE
- Date Published:
- Format(s):
- Medium: X
- Location:
- Liverpool, United Kingdom
- Sponsoring Org:
- National Science Foundation
More Like this
-
-
Code changes are often reviewed before they are deployed. Popular source control systems aid code review by presenting textual differences between old and new versions of the code, leaving developers with the difficult task of determining whether the differences actually produced the desired behavior. Fortunately, we can mine such information from code repositories. We propose aiding code review with inter-version semantic differential analysis. During review of a new commit, a developer is presented with summaries of both code differences and behavioral differences, which are expressed as diffs of likely invariants extracted by running the system's test cases. As a result, developers can more easily determine that the code changes produced the desired effect. We created an invariant-mining tool chain, GETTY, to support our concept of semantically-assisted code review. To validate our approach, 1) we applied GETTY to the commits of 6 popular open source projects, 2) we assessed the performance and cost of running GETTY in different configurations, and 3) we performed a comparative user study with 18 developers. Our results demonstrate that semantically-assisted code review is feasible, effective, and that real programmers can leverage it to improve the quality of their reviews.more » « less
-
null (Ed.)This research paper examines students’ perceptions of faculty and how it influences their identity trajectory. First-year students enter undergraduate engineering education with rich stories of how they came to choose engineering as a career pathway. Over time, the culture of engineering and network of peers, faculty members, and professionals shape students' stories and identity trajectories. How students “cast” faculty members in their story, often as helpful or hurtful actors, have implications for their identity trajectory, success, and, ultimately, retention in engineering. In this paper, we used two composite narratives constructed from longitudinal narrative interviews with 16 students to illustrate how students cast faculty into a role as either a support or an obstacle, based on their classroom experiences and interactions with them. This paper highlights the interactions that led these students to view faculty as helpful or harmful and explores the effects resulting: influence over student identity trajectory by fostering or hindering relationship building and networking, as well as influencing intellectual growth and personal ability beliefs.more » « less
-
Developers in open source projects must make decisions on contributions from other community members, such as whether or not to accept a pull request. However, secondary factors—beyond the code itself—can influence those decisions. For example, signals from GitHub profiles, such as a number of followers, activity, names, or gender can also be considered when developers make decisions. In this paper, we examine how developers use these signals (or not) when making decisions about code contributions. To evaluate this question, we evaluate how signals related to perceived gender identity and code quality influenced decisions on accepting pull requests. Unlike previous work, we analyze this decision process with data collected from an eye-tracker. We analyzed differences in what signals developers said are important for themselves versus what signals they actually used to make decisions about others. We found that after the code snippet (x=57%), the second place programmers spent their time fixating on supplemental technical signals(x=32%), such as previous contributions and popular repositories. Diverging from what participants reported themselves, we also found that programmers fixated on social signals more than recalled.more » « less
-
Narrative planning is the use of automated planning to construct, communicate, and understand stories, a form of information to which human cognition and enaction is pre-disposed. We review the narrative planning problem in a manner suitable as an introduction to the area, survey different plan-based methodologies and affordances for reasoning about narrative, and discuss open challenges relevant to the broader AI community.more » « less
An official website of the United States government

