The emotional side of software developers in JIRA

Issue tracking systems store valuable data for testing hypotheses concerning maintenance, building statistical prediction models and (recently) investigating developer affectiveness. For the latter, issue tracking systems can be mined to explore developers emotions, sentiments and politeness |affects for short. However, research on affect detection in software artefacts is still in its early stage due to the lack of manually validated data and tools. In this paper, we contribute to the research of affects on software artefacts by providing a labeling of emotions present on issue comments. We manually labeled 2,000 issue comments and 4,000 sentences written by developers with emotions such as love, joy, surprise, anger, sadness and fear. Labeled comments and sentences are linked to software artefacts reported in our previously published dataset (containing more than 1K projects, more than 700K issue reports and more than 2 million issue comments). The enriched dataset presented in this paper allows the investigation of the role of affects in software development

Four-Dimensional Sustainable E-Services

E-services are not sustainable, unless we specifically design for sustainability along four dimensions (4D): economical, technical, environmental, and social. Economic sustainability to ensure that e-services create economic value; technical sustainability so that their technical assets actually enable the e-services to cope with changes; environmental sustainability to avoid that e-services harm the environment they operate in, and social sustainability to ensure e-services provide fair exchange of information between parties. Designing 4D-sustainable e-services is very complex. So far, service-engineering research has left dealing with such complexity unassisted—mainly due to the many initial technical challenges that needed to be overcome. Our goal is to fill this gap, by modeling the fundamentals of 4D-sustainable e-services. We propose a conceptual approach for representing 4D-sustainability. Our goal is to enhance the shared understanding amongst sustainability stakeholders, and to ease sustainability assessment and negotiation. Our approach offers a number of interrelated core elements (common among the four sustainability dimensions) as well as dimension-specific elements, variable elements. By focusing on 4D core elements, we enable describing the essence of sustainable e-services in a unified manner. We illustrate the value of the conceptual model using a real-life case study featuring an airport baggage handling syste

Security but not for security’s sake: The impact of social considerations on app developers’ choices

We explore a dataset of app developer reasoning to better understand the reasons that may inadvertently promote or demote app developers' prioritization of security. We identify a number of reasons: caring vs. fear of users, the impact of norms, and notions of 'otherness' and 'self' in terms of belonging to groups. Based on our preliminary findings, we propose an interdisciplinary research agenda to explore the impact of 'social identity (a psychological theory) on developers’ security rationales, and how this could be leveraged to guide developers towards making more secure choices

Splicing Community and Software Architecture Smells in Agile Teams: An industrial Study

Software engineering nowadays largely relies on agile methods to carry out software development. In often highly distributed organizations, agile teams can develop organisational and socio-technical issues loosely defined as community smells, which reflect sub-optimal organisational configurations that bear additional project cost, a phenomenon called social debt. In this paper we look into the co-occurrence of such nasty organisational phenomena—community smells—with software architecture smells—indicators that software architectures may exhibit sub-optimal modularization structures, with consequent additional cost. We conclude that community smells can serve as a guide to steer the qualities of software architectures within agile teams

“The Second Vice is Lying, the First is Running into Debt.” Antecedents and Mitigating Practices of Social Debt: an Exploratory Study in Distributed Software Development Teams

Although much is known about the concept of technical debt in software development, less is known about its social counterpart, also known as social debt. Social debt refers to future consequences of decisions related to people and their interactions. Omissions in social interactions or reduction of communication can foster social debt – and in turn result in negative outcomes in the long run. In this paper, we explore what factors drive and mitigate social debt in distributed agile software development teams. Utilizing an exploratory case study approach, we derive insights from two case organizations. We present antecedents and mitigating factors of social debt related to communication, collaboration, and coordination

Social Debt in Software Engineering: Insights from Industry

Social debt is analogous to technical debt in many ways: it represents the state of software development organisations as the result of “accumulated” decisions. In the case of social debt, decisions are about people and their interactions. Our objective was to study the causality around social debt in practice. In so doing, we conducted exploratory qualitative research in a large software company. We found many forces together causing social debt; we represented them in a framework, and captured anti-patterns that led to the debt in the first place. Finally, we elicited best practices that technicians adopted to pay back some of the accumulated debt. We learned that social debt is strongly correlated with technical debt and both forces should be reckoned with together during the software process

Ohjelmistoprojektin riskien ja prosessien hallinta startup-yrityksessä: Tapaustutkimus

Software projects are notorious for their failure rates and software maintenance is a complex task that often becomes more time-consuming as the software ages. In modern software development, maintenance is often done in an iterative fashion with the help of continuous integration and deployment tools to help with quality assurance. This thesis is a postmortem case study of the design and development involved in a user interface rewrite project conducted for a healthtech SaaS-product. The focus of the study is on investigating how efficient the methods of working were, what pain points were identified and how well the risks were managed for the project. It aims to provide insight on how early-stage companies with limited resources can see through a sizable effort such as this efficiently. Focus is also given to whether a transition towards a microservice-architecture is a viable choice within this context. The key findings from the conducted case study are that even when following agile practices, a systematic approach to software engineering is essential for success. Projects should have a clear scope and clear responsibilities in order for their success to be measurable. Team composition and individual skills are the crucial elements in a development team, and tools and practices only strengthen the results of individuals. However, open communication, motivated individuals and visibility into progress are also essential.Ohjelmistoprojektien epäonnistuminen on tutkitusti yleistä ja ohjelmistojen ylläpito on kompleksinen tehtävä, jonka vaatimat resurssit usein kasvavat ohjelmiston vanhetessa. Modernissa ohjelmistokehityksessä ylläpito usein tehdään iteratiivisesti, hyödyntäen jatkuvaa integraatiota laadunvarmistuksen apuna. Tämä diplomityö on tapaustutkimus terveysteknologiaan keskittyneen SaaS-sovelluksen uudistukseen liittyneestä kehitys- ja suunnittelutyöstä. Tutkielma keskittyy tutkimaan projektin riskinhallintaa, kehitysmetodien ja -prosessien tehokkuutta sekä löytämään näistä kipupisteitä. Työn tavoitteena on löytää resursseiltaan rajallisille alkuvaiheen ohjelmistoyrityksille soveltuvia työtapoja sekä selvittää, kuinka tämänkaltainen laaja kehitystyö voidaan suorittaa onnistuneesti. Tutkimus myös pyrkii selvittämään onko mikropalveluarkkitehtuuriin siirtyminen kannattavaa tässä kontekstissa. Työn tuloksena havaittiin, että systemaattinen lähestyminen ohjelmistokehitykseen on olennaista onnistumisen kannalta myös ketteriä menetelmiä hyödynnettäessä. Projekteilla tulisi olla selkeä laajuus ja selkeät tavoitteet, jotta projektin onnistumista voidaan mitata objektiivisesti. Kehitystiimin dynamiikka ja yksilöiden taidot ovat tärkein osa kehitystiimiä, ja työkaluilla ja menetelmillä on vain toissijainen vaikutus yksilöiden suorituskykyyn. Toisaalta myös avoin kommunikaatio, motivoituneet yksilöt ja kehityksen läpinäkyvyys ovat olennaisessa asemassa