Software Engineering (cs.SE)

Abstract: Pair programming (PP) has been a widespread practice for decades and is known for facilitating knowledge exchange and improving the quality of software. Many agilists advocated the importance of collocation, face-to-face interaction, and physical artifacts incorporated in the shared workspace when pairing. After a long period of forced work-from-home, many knowledge workers prefer to work remotely two or three days per week, which is affecting practices such as PP. In this revelatory single-case study, we aimed to understand how PP is practiced during hybrid work when team members alternate between on-site days and working from home. We collected qualitative and quantitative data through 11 semi-structured interviews, observations, feedback sessions, and self-reported surveys. The interviewees were members of an agile software development team in a Norwegian fintech company. The results presented in this paper indicate that PP can be practiced through on-site, remote, and mixed sessions, where the mixed mode seems to be the least advantageous. The findings highlight the importance of adapting the work environment to suit individual work mode preferences when it comes to PP. In the future, we will build on these findings to explore PP in other teams and organizations practicing hybrid work.

Abstract: This paper adopts a cognitive psychology perspective to investigate the recurring mistakes in code resulting from the mental set (Einstellung) effect. The Einstellung effect is the tendency to approach problem-solving with a preconceived mindset, often overlooking better solutions that may be available. This effect can significantly impact creative thinking, as the development of patterns of thought can hinder the emergence of novel and creative ideas. Our study aims to test the Einstellung effect and the two mechanisms of its overcoming in the field of programming. The first intervention was the change of the color scheme of the code editor to the less habitual one. The second intervention was a combination of instruction to "forget the previous solutions and tasks" and the change in the color scheme. During the experiment, participants were given two sets of four programming tasks. Each task had two possible solutions: one using suboptimal code dictated by the mental set, and the other using a less familiar but more efficient and recommended methodology. Between the sets, participants either received no treatment or one of two interventions aimed at helping them overcome the mental set. The results of our experiment suggest that the tested techniques were insufficient to support overcoming the mental set, which we attribute to the specificity of the programming domain. The study contributes to the existing literature by providing insights into creativity support during problem-solving in software development and offering a framework for experimental research in this field.

Abstract: Alloy is a declarative modeling language that is well suited for verifying system designs. Alloy models are automatically analyzed using the Analyzer, a toolset that helps the user understand their system by displaying the consequences of their properties, helping identify any missing or incorrect properties, and exploring the impact of modifications to those properties. To achieve this, the Analyzer invokes off-the-shelf SAT solvers to search for scenarios, which are assignments to the sets and relations of the model such that all executed formulas hold. To help write more accurate software models, Alloy has a unit testing framework, AUnit, which allows users to outline specific scenarios and check if those scenarios are correctly generated or prevented by their model. Unfortunately, AUnit currently only supports textual specifications of scenarios. This paper introduces Crucible, which allows users to graphically create AUnit test cases. In addition, Crucible provides automated guidance to users to ensure they are creating well structured, valuable test cases. As a result, Crucible eases the burden of adopting AUnit and brings AUnit test case creation more in line with how Alloy scenarios are commonly interacted with, which is graphically.