Giuseppe Destefanis

Software development: do good manners matter?

The research presented in this paper was partly funded by the Engineering and Physical Sciences Research Council (EPSRC) of the UK under grant ref: EP/M024083/1.

Mining valence, arousal, and dominance: possibilities for detecting burnout and productivity?

Similar to other industries, the software engineering domain is plagued by psychological diseases such as burnout, which lead developers to lose interest, exhibit lower activity and/or feel powerless. Prevention is essential for such diseases, which in turn requires early identification of symptoms. The emotional dimensions of Valence, Arousal and Dominance (VAD) are able to derive a person’s interest (attraction), level of activation and perceived level of control for a particular situation from textual communication, such as emails. As an initial step towards identifying symptoms of productivity loss in software engineering, this paper explores the VAD metrics and their properties on 700,000 Jira issue reports containing over 2,000,000 comments, since issue reports keep track of a developer’s progress on addressing bugs or new features. Using a general-purpose lexicon of 14,000 English words with known VAD scores, our results show that issue reports of different type (e.g., Feature Request vs. Bug) have a fair variation of Valence, while increase in issue priority (e.g., from Minor to Critical) typically increases Arousal. Furthermore, we show that as an issue’s resolution time increases, so does the arousal of the individual the issue is assigned to. Finally, the resolution of an issue increases valence, especially for the issue Reporter and for quickly addressed issues. The existence ofsuch relations between VAD and issue report activities shows promise that text mining in the future could offer an alternative way for work health assessment surveys.

The emotional side of software developers in JIRA

ABSTRACTIssue tracking systems store valuable data for testing hy-potheses concerning maintenance, building statistical pre-diction models and (recently) investigating developer affec-tiveness. For the latter, issue tracking systems can be minedto explore developers emotions, sentiments and politeness, affects for short. However, research on affect detection insoftware artefacts is still in its early stage due to the lack ofmanually validated data and tools.In this paper, we contribute to the research of affectson software artefacts by providing a labeling of emotionspresent on issue comments.We manually labeled 2,000 issue comments and 4,000 sen-tences written by developers with emotions such as love,joy, surprise, anger, sadness and fear. Labeled commentsand sentences are linked to software artefacts reported inour previously published dataset (containing more than 1Kprojects, more than 700K issue reports and more than 2million issue comments). The enriched dataset presented inthis paper allows the investigation of the role of affects insoftware development.

Micro Pattern Fault-Proneness

One of the goals of Software Engineering is to reduce, or at least to try to control, the defectiveness of software systems during the development phase. The aim of our study is to analyze the relationship between micro patterns (introduced by Gil and Maman) and faults in a software system. Micro patterns are similar to design patterns, but their characteristic is that they can be identified automatically, and are at a lower level of abstraction with respect to design patterns. Our study aims to show, through empirical studies of open source software systems, which categories of micro patterns are more correlated to faults. Gil and Maman demonstrated, and subsequent studies confirmed, that 75% of the classes of a software system are covered by micro patterns. In our study we also analyze the relationship between faults and the remaining 25% of classes that do not match with any micro pattern. We found that these classes are more likely to be fault-prone than the others. We also studied the correlation among all the micro patterns of the catalog, in order to verify the existence of relationships between them.

An empirical study of software metrics for assessing the phases of an agile project

We present an analysis of the evolution of a Web application project developed with object-oriented technology and an agile process. During the development we systematically performed measurements on the source code, using software metrics that have been proved to be correlated with software quality, such as the Chidamber and Kemerer suite and Lines of Code metrics. We also computed metrics derived from the class dependency graph, including metrics derived from Social Network Analysis. The application development evolved through phases, characterized by a different level of adoption of some key agile practices — namely pair programming, test-based development and refactoring. The evolution of the metrics of the system, and their behavior related to the agile practices adoption level, is presented and discussed. We show that, in the reported case study, a few metrics are enough to characterize with high significance the various phases of the project. Consequently, software quality, as measured using these metrics, seems directly related to agile practices adoption.

Micro Patterns in Agile Software

In this paper we present a study on micro patterns in different releases of two software systems developed with Object Oriented technologies and Agile process. Micro patterns are design decisions in code that can be easily automatically recognised. Gil and Maman introduced the concept to support providing objective assessment of design decisions [1]. They catalogued 27 micro patterns that capture a variety of programming practices in Java. Micro patterns can be a useful metrics in order to measure the quality of software by showing that certain categories of micro patterns are more fault prone than others, and that the classes that do not correspond to any category of micro patterns are more likely to be faulty. In our study we present some empirical results on two case studies of systems developed with Agile methodologies, and compare them to previous results obtained for non Agile systems. In particular we have verified that the distribution of micro patterns in a software system developed using Agile methodologies does not differ from the distribution studied in other systems, and that the micro patterns fault-proneness is about the same. We also analyzed how the distribution of micro patterns changes in different releases of the same software system. We demonstrate that there is a relationship between the number of faults and the classes that do not match with any micro patterns. We found that these classes are more likely to be fault-prone than the others even in software developed with Agile methodologies.

Would you mind fixing this issue

A successful software project is the result of a complex process involving, above all, people. Developers are the key factors for the success of a software development process and the Agile philosophy is developer-centred. Developers are not merely executors of tasks, but actually the protagonists and core of the whole development process. This paper aims to investigate social aspects among developers working together and the appeal of a software project developed with the support of Agile tools such as Agile boards. We studied 14 open source software projects developed using the Agile board of the JIRA repository. We analysed all the comments committed by the developers involved in the projects and we studied whether the politeness of the comments affected the number of developers involved over the years and the time required to fix any given issue. Our results show that the level of politeness in the communication process among developers does have an effect on the time required to fix issues and, in the majority of the analysed projects, it has a positive correlation with attractiveness of the project to both active and potential developers. The more polite developers were, the less time it took to fix an issue, and, in the majority of the analysed cases, the more the developers wanted to be part of project, the more they were willing to continue working on the project over time.

An analysis of anti-micro-patterns effects on fault-proneness in large Java systems

Micro patterns are similar to design patterns, but are at a lower level of abstraction, closer to the implementation. Anti patterns are micro patterns not respecting the prescriptions of good Object Oriented programming practices. In this paper, we use the definitions introduced by Arcelli and Maggioni [3] in order to study the evolution of five particular micro patterns (anti patterns) in different releases of the Eclipse and NetBeans systems, and the correlations between anti patterns and faults. Our analysis confirms previous findings regarding the high coverage of micro patterns onto the system classes, and show that anti patterns not only represent bad Object Oriented programming practices, but may also be associated to the production of lower quality software, since they present a fault proneness significantly enhanced.

Arsonists or firefighters? Affectiveness in agile software development

In this paper, we present an analysis of more than 500 K comments from open-source repositories of software systems developed using agile methodologies. Our aim is to empirically determine how developers interact with each other under certain psychological conditions generated by politeness, sentiment and emotion expressed within developers’ comments. Developers involved in an open-source projects do not usually know each other; they mainly communicate through mailing lists, chat, and tools such as issue tracking systems. The way in which they communicate affects the development process and the productivity of the people involved in the project. We evaluated politeness, sentiment and emotions of comments posted by agile developers and studied the communication flow to understand how they interacted in the presence of impolite and negative comments (and vice versa). Our analysis shows that “firefighters” prevail. When in presence of impolite or negative comments, the probability of the next comment being impolite or negative is 13 % and 25 %, respectively; ANGER however, has a probability of 40 % of being followed by a further ANGER comment. The result could help managers take control the development phases of a system, since social aspects can seriously affect a developer’s productivity. In a distributed agile environment this may have a particular resonance.

How diverse is your team? Investigating gender and nationality diversity in GitHub teams

BackgroundBuilding an effective team of developers is a complex task faced by both software companies and open source communities. The problem of forming a “dream”team involves many variables, including consideration of human factors and it is not adilemma solvable in a mathematical way. Empirical studies might provide interesting insights to explain which factors need to be taken into account in building a team of developers and which levers act to optimise productivity among developers.AimIn this paper, we present the results of an empirical study aimed at investigating the link between team diversity (i.e., gender, nationality) and productivity (issue fixing time).MethodWe consider issues solved from the GHTorrent dataset inferring gender and nationality of each team’s members. We also evaluate the politeness of all comments involved in issue resolution.ResultsResults show that higher gender diversity is linked with a lower team average issue fixing time (higher productivity), that nationality diversity is linked with lower team politeness and that gender diversity is linked with higher sentiment.