Tiago Massoni

Flávia Coelho, Nikolaos Tsantalis, Tiago Massoni et al.

Background: Pull-based development has shaped the practice of Modern Code Review (MCR), in which reviewers can contribute code improvements, such as refactorings, through comments and commits in Pull Requests (PRs). Past MCR studies uniformly treat all PRs, regardless of whether they induce refactoring or not. We define a PR as refactoring-inducing, when refactoring edits are performed after the initial commit(s), as either a result of discussion among reviewers or spontaneous actions carried out by the PR developer. Aims: This mixed study (quantitative and qualitative) explores code reviewing-related aspects intending to characterize refactoring-inducing PRs. Method: We hypothesize that refactoring-inducing PRs have distinct characteristics than non-refactoring-inducing ones and thus deserve special attention and treatment from researchers, practitioners, and tool builders. To investigate our hypothesis, we mined a sample of 1,845 Apache's merged PRs from GitHub, mined refactoring edits in these PRs, and ran a comparative study between refactoring-inducing and non-refactoring-inducing PRs. We also manually examined 2,096 review comments and 1,891 detected refactorings from 228 refactoring-inducing PRs. Results: We found 30.2% of refactoring-inducing PRs in our sample and that they significantly differ from non-refactoring-inducing ones in terms of number of commits, code churn, number of file changes, number of review comments, length of discussion, and time to merge. However, we found no statistical evidence that the number of reviewers is related to refactoring-inducement. Our qualitative analysis revealed that at least one refactoring edit was induced by review in 133 (58.3%) of the refactoring-inducing PRs examined. Conclusions: Our findings suggest directions for researchers, practitioners, and tool builders to improve practices around pull-based code review.

Marzina Vidal, Tiago Massoni, Franklin Ramalho

Software requirement analysis can certainly benefit from prevention and early detection of failures, in particular by some kind of automatic analysis. Formal methods offer means to represent and analyze requirements with rigorous tools, avoiding ambiguities and allowing automatic verification of requirement consistency. However, formalisms often clash in the culture or lack of skills of software analysts, making them challenging to apply. In this article, we propose a Domain-Specific Language (DSL) based on Set Theory for requirement analysts. The Graphical InvaRiant Language (GIRL) can be used to specify software requirement structural invariants, with entities and their relationships. Those invariants can then have their consistency evaluated by the Alloy Analyzer, based on a mapping semantics we provide for transforming GIRL models into Alloy specifications with no user intervention. With a prototypical language editor and transformations implemented into an Eclipse plugin, we carried out a qualitative study with requirement analysts working for a government software company in Brazil, to evaluate usability and effectiveness of the GIRL-based analysis of real software requirements. The participants were able to effectively use the underlying formal analysis, since 79 out of 80 assigned invariants were correctly modeled. While participants perceived as low the complexity of learning and using GIRL's simplest, set-based structures and relationships, the most complex logical structures, such as quantification and implication, were challenging. Furthermore, almost all post-study evaluations from the participants were positive, especially as a tool for discovering requirement inconsistencies.

Tiago Massoni, Nilton Ginani, Wallison Silva et al.

High rates of turnover among software developers remain, involving additional costs of hiring and training. Voluntary turnover may be due to workplace issues or personal career decisions, but it might as well relate to Job Characteristics, or even Job Satisfaction and Work Exhaustion. This paper reports on an initial study which quantitatively measured those constructs among 78 software developers working in Brazil who left their jobs voluntarily. For this, we adapted well-known survey instruments, namely the JDS from Hackman and Oldham's Job Characteristics Model, and Maslach et al.'s Burnout Measurement. In average, developers demonstrated low to moderate autonomy (3.75, on a 1-7 scale) and satisfaction (4.08), in addition to moderate exhaustion (4.2) before leaving their jobs, while experiencing high task significance (5.15). Also, testers reported significantly lower job satisfaction than programmers. These results allow us to raise interesting hypotheses to be addressed by future studies.