Figure 1 - uploaded by Jürgen Münch
Content may be subject to copyright.
Developer Experience: Conceptual framework. 

Developer Experience: Conceptual framework. 

Source publication
Conference Paper
Full-text available
New ways of working such as globally distributed development or the integration of self-motivated external developers into software ecosystems will require a better and more comprehensive understanding of developers' feelings, perceptions, motivations and identification with their tasks in their respective project environments. User experience is a...

Context in source publication

Context 1
... of one's own goals with those of the project, plans, intentions, and commitment). Figure 1 shows the concept of DE x as an interaction between cognitive, affective, and conative factors. Each dimension of DE x consists of a multitude of complex sub-factors. ...

Similar publications

Article
Full-text available
The paper seeks to provide an analysis on the main factors which determine the dynamics of production and innovation in the scope of HEIC. In doing so, it seeks to examine the relation between the health production system and the health innovation system in Brazil. Therefore, health sector is seen as an interdependent economic space that characteri...
Thesis
Full-text available
The dissertation presents the work done under the scope of the NP7 Self-Learning project regarding the design and development of the Adapter component as a foundation for the Self-Learning Production Systems (SLPS). This component is responsible to confer additional proprieties to production systems such as lifecycle learning, optimization of proce...
Article
Full-text available
This paper deals with formal modelling of Petri nets including shared resources. These phenomena appear widely in the production management context, for the modelling of manufacturing cells. But, they usually cannot be formally represented in dioid algebraic structures based on sets of scalars. In this paper, we design a method to describe such a p...

Citations

... Improving developer happiness and satisfaction is an important goal for many companies as doing so may lead to higher levels of productivity [1], [2], [3], [4] and improve worker retention [5]. Previous research has focused on understanding and eliciting factors that help describe or predict developer productivity and satisfaction [1], [2], [3], [4], [6] and which factors may impact developers' productivity and satisfaction with their work depends on individual, team, organization and project context [3]. ...
... Developer experience, as defined by Fagerholm and Münch [6], is a broader concept that captures how developers feel about, think about and value their work. This definition emerged from a review of the literature and these authors claim that developer experience is also shaped by many factors, including team culture, working environment and work activities, but, like satisfaction, is also highly personal. ...
... Our definition is inspired by Fagerholm and Münch [6] and as such is rooted in social psychology from the concept of the trilogy of the mind [7] where the three main dimensions of human experience are cognition (thinking), affect (emotion) and conation (volition to act). Consideration of these three dimensions of experience is important as "real-world problem solving operates in concert with motivational and emotional processes, sometimes harmoniously and sometimes discordantly." ...
Preprint
Developer experience is an important concern for software organizations as enhancing developer experience improves productivity, satisfaction, engagement and retention. We set out to understand what affects developer experience through semi-structured interviews with 21 developers from industry, which we transcribed and iteratively coded. Our findings elucidate factors that affect developer experience and characteristics that influence their respective importance to individual developers. We also identify strategies employed by individuals and teams to improve developer experience and the barriers that stand in their way. Lastly, we describe the coping mechanisms of developers when developer experience cannot be sufficiently improved. Our findings result in the DX Framework, an actionable conceptual framework for understanding and improving developer experience. The DX Framework provides a go-to reference for organizations that want to enable more productive and effective work environments for their developers.
... • number of components (could be separated into artifacts) Most of the cases, the human resource cost is the largest factor of a software project budget. Making every team member locally run integration tests before commiting changes to the source is inefficient, not mentioning the decrease of developer experience (DX) which causes decreasing productivity of each individual developer, which again shows inefficiency [4]. ...
Article
Continuous Integration (CI) is an essential approach in modern software engineering. CI tools help merging the recent commits from the developers, thus the bugs can be realized in an early phase of development and integration hell can be avoided. Jenkins is the most well-known and most widely-used CI tool. Pipelines become first-class citizen in Jenkins 2. Pipelines consist of stages, such as compiling, building Docker image, integration testing, etc. However, comprehensive Jenkins pipelines are hard to see through and understand. In this paper, we argue for a modern visualisation of Jenkins pipelines. We present our solution for making Jenkins pipelines comprehensible on the dashboard.
... An evangelist is a keystone' employee that is responsible to support external developers in developing contributions to the MSECO platform [6]. In this context, Developer eXperience (DX) consists of experiences developers may have as part of their involvement in the software development process in an MSECO [7]. ...
... Developer eXperience (DX) [7] consists of experiences related to all types of artifacts and activities a developer may perform as part of his/her involvement in mobile application development. We can mention as sources of DX: (a) infrastructure development -management and development tools, programming languages, libraries, platforms, processes, and methods; (b) perceptions about the work -respect and recognition; and (c) sense of contribution -alignment of developers' work and contributions regarding the keystone's objectives and plans. ...
Conference Paper
In a Mobile Software Ecosystem (MSECO), large software organizations (or keystones) need to attract/coach external developers to meet users’ demands. In this scenario, it is necessary to evaluate developers’ experiences during their involvement in trainings as a strategy to engage developers to contribute to the MSECO expansion (quantitatively and qualitatively). In this paper, we report a study on the comparison of a process-based approach for training mobile application developers in MSECO against an ad hoc approach (developer’s and evangelist’s personal processes) to analyze the effect of evangelist-developers interaction in MSECO from Developer eXperience (DX). We also propose a set of steps to assist keystone organizations to govern developers based on DX sources and with evangelists’ support in trainings
... Several studies have shown that human factors are the most important factors for software development, both in terms of performance and quality [1] [2][3] [4]. Moreover, concepts have been defined in order to understand the participation and experience of different actors involved in the software development, such as Users and Developers. ...
... UX is a term that captures how people feel about products, systems and services [5]. DX is a means of capturing how developers think and feel about their activities within their software development environments [1]. ...
... Developer Experience (DX) consists of experiences relating to all kinds of artifacts and activities that a developer may encounter as part of his/her involvement in software development [1]. Fagerholm et al. [1] discuss that DX could be divided into experiences regarding: development infrastructure, feelings about, and the value of one's own contribution. ...
... In this paper, we aim to cast light on how professional software developers experience performance in a Lean and Agile context. Drawing on a previous conceptualisation of Developer Experience [23], we approach the issue through a cognitive, a↵ective, and conative lens. We view team performance from the perspective of individual software practitioners, gaining insights that may be of use in evaluating teams from an internal perspective. ...
Conference Paper
Full-text available
Context: Companies increasingly strive to adapt to market and ecosystem changes in real time. Evaluating team performance in such changing environments presents a major challenge. Objective: This paper aims to understand how software developers experience performance in a highly volatile environment. This understanding could be used as a basis for guiding formation and maintenance of high-performing teams. Method: A qualitative multiple-case study using thematic interviews was conducted with 16 experienced practitioners in five organisations. Results: We found 33 major cate-gories of performance factors, arranged as a theoretical structure that explains how the subjects experience software team performance. Conclusions: Based on our study, software teams are engaged in a constant cycle of interpreting their performance and aligning it with other stakeholders. Enhancing performance experiences requires integration of soft factors, such as communication, team spirit, and team identity, into the overall development process.
Conference Paper
Full-text available
Developer Experience (DX) is defined concerning how developers think, feel and value their work. Considering that developers’ satisfaction and feelings impact the productivity and success of projects, it is necessary to understand how to improve their experience throughout the stages of the development process. Within this context, we investigated the developer experience and the main factors that affect using a collaborative UML diagram modeling tool. For this, we use three techniques as evaluation methods: the DEXI scale, the Intrinsic Motivation Inventory, and Focus Group. We executed an empirical study with 20 people learning to use a modeling tool. Qualitative results highlight that the organization of user interface components and specific support aspects for collaborative work affected DX at different levels. Other essential elements, such as ease of use, rework, and organization, were also identified. The results aim to improve developers' experience in software modeling tools, making the experience satisfactory and pleasant.
Chapter
API-Plattformen können als zweiseitige Marktplätze betrachtet werden. Aus Sicht der API-Anbieter stellen die Plattformen einen Hauptvertriebskanal für selbstentwickelte APIs dar. Unterschiedliche Monetisierungsmodelle helfen den Anbietern dabei, den eigenen Umsatz durch die Bereitstellung von APIs zu erhöhen. Aus der Sicht der Nachfrager bilden die Plattformen eine zentrale Anlaufstelle, um sich über die Vielfalt und Möglichkeiten der bereits vorhandenen APIs zu informieren. Wird die passende API auf einem digitalen Marktplatz gefunden, so kann diese in der Regel komfortabel und mit hoher Geschwindigkeit in die eigenen Applikationen bzw. IT-Systeme integriert werden.
Chapter
The concept of low-code (and no-code) platforms has been around for decades, even before the term was used. The idea is that applications on these platforms can be built by people with less technical expertise than a professional programmer, yet can leverage powerful technology such as, for example, for databases, financial analysis, web development and machine learning. However, in practice, software written on such platforms often accumulates large volumes of complex code, which can be worse to maintain than in traditional languages because the low-code platforms tend not to properly support good engineering practices such as version control, separation of concerns, automated testing and literate programming. In this paper we discuss experiences with several low-code platforms and provide suggestions for directions forward towards an era where the benefits of low-code can be obtained without accumulation of technical debt. Our recommendations focus on ensuring low-code platforms enable scaling, understandability, documentability, testability, vendor-independence, and the overall user experience for developers those end-users who do some development.