Armando Fox

Cesar Garcia, Alejandro Guerrero, Joshua Zeitsoff et al.

Agile software teams are expected to follow a number of specific Team Practices (TPs) during each iteration, such as estimating the effort ("points") required to complete user stories and coordinating the management of the codebase with the delivery of features. For software engineering instructors trying to teach such TPs to student teams, manually auditing teams if teams are following the TPs and improving over time is tedious, time-consuming and error-prone. It is even more difficult when those TPs involve two or more tools. For example, starting work on a feature in a project-management tool such as Pivotal Tracker should usually be followed relatively quickly by the creation of a feature branch on GitHub. Merging a feature branch on GitHub should usually be followed relatively quickly by deploying the new feature to a staging server for customer feedback. Few systems are designed specifically to audit such TPs, and existing ones, as far as we know, are limited to a single specific tool. We present Bluejay, an open-source extensible platform that uses the APIs of multiple tools to collect raw data, synthesize it into TP measurements, and present dashboards to audit the TPs. A key insight in Bluejay's design is that TPs can be expressed in terminology similar to that used for modeling and auditing Service Level Agreement (SLA) compliance. Bluejay therefore builds on mature tools used in that ecosystem and adapts them for describing, auditing, and reporting on TPs. Bluejay currently consumes data from five different widely-used development tools, and can be customized by connecting it to any service with a REST API. Video showcase available at governify.io/showcase/bluejay

Natalie Kiesler, Jacqueline Smith, Juho Leinonen et al.

Collaboration is a crucial part of computing education. The increase in AI capabilities over the last couple of years is bound to profoundly affect all aspects of systems and software engineering, including collaboration. In this position paper, we consider a scenario where AI agents would be able to take on any role in collaborative processes in computing education. We outline these roles, the activities and group dynamics that software development currently include, and discuss if and in what way AI could facilitate these roles and activities. The goal of our work is to envision and critically examine potential futures. We present scenarios suggesting how AI can be integrated into existing collaborations. These are contrasted by design fictions that help demonstrate the new possibilities and challenges for computing education in the AI era.

Amador Durán, Pablo Fernández, Beatriz Bernárdez et al.

Context. Pair programming (PP) has been found to increase student interest in Computer Science, particularly so for women, and would therefore appear to be a way to help remedy their under-representation, which could be partially motivated by gender stereotypes applied to software engineers, assuming that men perform better than their women peers. If this same bias is present in pair programming, it could work against the goal of improving gender balance. Objective. In a remote setting in which students cannot directly observe their peers, we aim to explore whether they behave differently when the perceived gender of their remote PP partners changes, searching for differences in (i) the perceived productivity compared to solo programming; (ii) the partner's perceived technical competency compared to their own; (iii) the partner's perceived skill level; (iv) the interaction behavior, such as the frequency of source code additions, deletions, etc.; and (v) the type and relative frequencies of dialog messages in a chat window. Method. Using the twincode platform, several behaviors are automatically measured during the remote PP process, together with two questionnaires and a semantic tagging of the pairs' chats. A series of experiments to identify the effect, if any, of possible gender bias shall be performed. The control group will have no information about their partner's gender, whereas the treatment group will receive such information but will be selectively deceived about their partner's gender. For each response variable we will (i) compare control and experimental groups for the score distance between two in-pair tasks; then, using the data from the experimental group only, we will (ii) compare scores using the partner's perceived gender as a within-subjects variable; and (iii) analyze the interaction between the partner's perceived gender and the subject's gender.