Boundary artefacts are shared artefacts that support collaboration by allowing different groups to interpret the same information in different ways. Software development activities benefit from them, as a single artefact can support stakeholders across different organisational boundaries. When these artefacts contain inconsistencies, such as incorrect information, practitioners’ trust in them may decrease, leading to inefficiencies in task execution. This study developed and evaluated a guideline to support the creation of boundary artefacts in software engineering contexts. We conducted a longitudinal, multi-phase study embedded in an industrial setting. The guideline was developed based on a literature review and prior findings from a previous case study and was then submitted for practitioner evaluation. A post-implementation analysis of the guideline was carried out after a period without researcher intervention. Our guideline consists of 10 principles grouped into three categories: (1) Scope: stakeholders, boundaries, and terminology; (2) Structure: artefact format, transference, granularity, and additions; and (3) Management: evaluation, ownership, governance, and integration. Practitioner evaluations suggested that these principles support the creation of reliable, predictable, and functional boundary artefacts. However, practitioners also noted challenges during use, including the time-consuming nature of the activity and difficulties in understanding the concept of boundary artefact. Overall, the guideline was well received. After the non-intervention period, it was adopted as a standard by the partner company for artefacts such as security testing, standards documentation, and requirements specifications. Adoption challenges persisted, including cultural barriers and comprehension issues. Further applications across different artefacts could clarify how the principles influence their reliability, functionality, and predictability.

Low-code development (LCD) is an emerging trend in current software development. Alongside growing industry interest, academic research on the topic has also expanded rapidly, raising questions about the viability of LCD—its practical effectiveness, benefits, and challenges—across different contexts. We performed a systematic literature review of articles published between 2021 and early 2025. Of the 1006 articles identified through database searches, 226 met the inclusion criteria and were analyzed. We examined publication trends, definitions of LCD, and target user groups. Reported benefits and challenges were categorized into seven thematic areas, within which we analyzed contextual applications and assessed the strength of supporting evidence. We also investigated the social aspects of LCD adoption to better understand its human and organizational dimensions. Based on the findings, there is sufficient evidence showing that LCD speeds up development and that quality and complexity have mixed and context-dependent outcomes. Open questions remain regarding costs and security. This review provides insights into the viability of LCD and offers recommendations to guide future studies and advance both the understanding and practice of LCD. Editor’s note: Open Science material was validated by the Journal of Systems and Software Open Science Board .

Collaborative learning in groups has practical and pedagogical benefits. In software engineering education, the group formation stage can have an important influence on the quality of learning and students' satisfaction with their group. Knowledge of student experiences and preferences regarding group formation can inform course design and hopefully lead to better learning outcomes and student satisfaction. In this paper, we report experiences of group formation in software engineering courses, focusing on students' perspectives. We used surveys administered on three master's level software engineering courses, through which we explored students' prior experiences with group work in educational settings and their perspectives on how groups should be formed. We present results on students' thoughts about who should form groups, what information criteria they would consider as relevant when forming groups, and what kind of group formation strategy they prefer. Our results indicate that students preferred to keep the group formation process in their own hands, that they considered grade ambitions, educational background, and time availability to be important factors to consider, and that they generally preferred the formation strategy already used on the courses they attended. We also discuss how students' prior experiences may have coloured their perceptions of group formation strategies and the ethical dilemmas facing instructors when choosing different strategies. We present points of consideration for teachers who are interested in improving group formation on their software engineering courses.

Continuous experimentation relies on the design and implementation of experiment objects: artefacts that are used as the treatment or stimulus in a software product experiment. To be used in practice, experiment objects must have traits that allow drawing correct inferences regarding a new product, while simultaneously being resource-efficient to produce. In this paper, we investigate what kinds of experiment objects companies use, how they are selected, what factors influence the selection, and how they evolve over time. We present a multiple-case study based on semi-structured interviews with representatives from eight companies. Four kinds of experiment objects were found: prototypes, minimum viable products, proofs-of-concept, and wireframes. The results show that deciding what kind of experiment object to develop is a collaborative and customer-oriented process. As experimentation proceeds, experiment objects can be thrown away, modified for new experiments, or even become products. Experiment objects were understood not only as artefacts in product experiments, but blended with purposes familiar from prototyping and user interface and experience design, and they were used as vehicles for customer communication. The study shows that experiment objects are created for a variety of purposes and understandings of experimentation. Guidelines for creating and managing effective experiment objects for different variations of continuous experimentation are called for.

Programmers encounter new Application Programming Interfaces (APIs) regularly as a part of their work. Difficulties in API comprehension affect programmers’ performance and the quality of the software they produce. To effectively support API comprehension, it is important to understand how programmers comprehend new APIs in real-life work contexts.In this study, we explore programmers’ initial API comprehension efforts. We analyze what information programmers need about an API before they are ready to start working with it and the actions and information sources they use to acquire this information. Furthermore, we identify different contextual factors that affect this process.We used the critical incident method to interview programmers about their API comprehension processes in work contexts. Our results show that before our participants were ready to start using an API for a task, they sought information about the API from various sources to assess its validity and evaluate it with respect to the requirements of the task. They used their background knowledge to steer their information-seeking efforts and to recognize key pieces of information that strengthened or weakened their confidence in the suitability of the API for the task at hand.As initial API comprehension and the resulting initial API mental models seem to guide further stages of programmers’ API comprehension efforts, they heavily influence the direction of the rest of the comprehension process. Therefore, it should be considered in the design of means to support API comprehension, such as API documentation.

Decision making pervades software and systems engineering. Intertemporal decisions involve trade-offs among outcomes at different points in time. They play a central role in systems design, as recognised since the inception of the software engineering (SE) field. They are also crucial for the sustainability of design decisions. However, temporal decision making is not adequately understood in SE. The field of Judgement and Decision Making (JDM) offers important empirical findings and research methods that could be utilised. This article establishes a baseline for studying how software professionals handle intertemporal choices. It examines how temporal distance affects choices in an example scenario, explores in what areas of software development such decisions can be found, and examines how systems design decisions can be characterised and studied as intertemporal. We developed a method to study intertemporal choice in SE, based on an initial set of psychological theory grounded in JDM. We instantiated the method in a study to elicit responses to an intertemporal choice task followed by a Cognitive Task Analysis (CTA) interview. We found that study participants overall tended to discount future outcomes, but individual participants varied wildly in how they valued present vs. future outcomes. They indicated several locations in which intertemporal choices occur in everyday software development. Based on these findings, and by reconciling our initial theory with existing JDM theory and results, we further developed and refined our theory and study method into a framework for studying intertemporal decision making in SE. To obtain a basis for more sustainable software systems design decisions, SE research should adopt a more comprehensive, detailed, and empirically consistent way of understanding and studying intertemporal choices. We provide suggestions for how future research could achieve practical methods that address essential characteristics of real-life systems design decisions.

Programmers’ mental models represent their knowledge and understanding of programs, programming concepts, and programming in general. They guide programmers’ work and influence their task performance. Understanding mental models is important for designing work systems and practices that support programmers. Although the importance of programmers’ mental models is widely acknowledged, research on mental models has decreased over the years. The results are scattered and do not take into account recent developments in software engineering. In this article, we analyze the state of research on programmers’ mental models and provide an overview of existing research. We connect results on mental models from different strands of research to form a more unified knowledge base on the topic. We conducted a systematic literature review on programmers’ mental models. We analyzed literature addressing mental models in different contexts, including mental models of programs, programming tasks, and programming concepts. Using nine search engines, we found 3678 articles (excluding duplicates). Of these, 84 were selected for further analysis. Using the snowballing technique, starting from these 84, we obtained a final result set containing 187 articles. We show that the literature shares a kernel of shared understanding of mental models. By collating and connecting results on mental models from different fields of research, we provide a comprehensive synthesis of results related to programmers’ mental models. The research field on programmers’ mental models faces many challenges arising from a lack of a shared knowledge base and poorly defined constructs. By creating a unified knowledge base on the topic, this work provides a basis for future work on mental models. We also point to directions for future studies. In particular, we call for studies that examine programmers working with modern practices and tools.

Boundary Artefacts (BAs) support software development activities in many aspects because it carries lots of information in the same object that can be used and interpreted by several social groups within an organisation. When the BAs are inconsistent regarding their content, such as many meanings or lack of contextual information, their efficiency is reduced because stakeholders won’t trust them. This study aimed to understand the implications of differences in the perception of trust on software projects and their influence on stakeholders’ behaviour. We conducted an exploratory case study to observe the creation and utilisation of one specific BA and the implications of differences in trust and their influence on stakeholders’ behaviour. : Our investigation has shown that practitioners adding and adjusting existing content do not entirely understand the stakeholders’ needs. Together with the partial management of the content, trust is impacted. When the content of BAs does not meet the trust factors, specifically reliability and predictability, the stakeholders can’t execute their tasks appropriately, and several implications affect the software development project. Additionally, they create workarounds to supply their needs. The differences in trust in BAs affect software projects in different areas of the organisation and interfere with the task execution of various stakeholders. The decrease in trust results from inconsistencies in the content associated with the lack of management of the BA. A structured strategy for representing and managing a BA’s content seems appropriate to increase trust levels and efficiency.

Developing software-intensive products or services usually involves a plethora of software artefacts. Assets are artefacts intended to be used more than once and have value for organisations; examples include test cases, code, requirements, and documentation. During the development process, assets might degrade, affecting the effectiveness and efficiency of the development process. Therefore, assets are an investment that requires continuous management. Identifying assets is the first step for their effective management. However, there is a lack of awareness of what assets and types of assets are common in software-developing organisations. Most types of assets are understudied, and their state of quality and how they degrade over time have not been well-understood. We performed an analysis of secondary literature and a field study at five companies to investigate and identify assets to fill the gap in research. The results were analysed qualitatively and summarised in a taxonomy. We present the first comprehensive, structured, yet extendable taxonomy of assets, containing 57 types of assets. The taxonomy serves as a foundation for identifying assets that are relevant for an organisation and enables the study of asset management and asset degradation concepts.

Context:There have been numerous recent calls for research on the human side of software engineering and its impact on various factors such as productivity, developer happiness and project success. An analysis of which challenges in software engineering teams are most frequent is still missing. As teams are more international, it is more frequent that their members have different human values as well as different communication habits. Additionally, virtual team setups (working geographically separated, remote communication using digital tools and frequently changing team members) are increasingly prevalent.Objective:We aim to provide a starting point for a theory about contemporary human challenges in teams and their causes in software engineering. To do so, we look to establish a reusable set of challenges and start out by investigating the effect of team virtualization. Virtual teams often use digital communication and consist of members with different nationalities that may have more divergent human values due to cultural differences compared to single nationality teams.Method:We designed a survey instrument and asked respondents to assess the frequency and criticality of a set of challenges, separated in context ”within teams” as well as ”between teams and clients”, compiled from previous empirical work, blog posts, and pilot survey feedback. For the team challenges, we asked if mitigation measures were already in place to tackle the challenge. Respondents were also asked to provide information about their team setup. The survey included the Personal Value Questionnaire to measure Schwartz human values. Finally, respondents were asked if there were additional challenges at their workplace. The survey was first piloted and then distributed to professionals working in software engineering teams via social networking sites and personal business networks.Result:In this article, we report on the results obtained from 192 respondents. We present a set of challenges that takes the survey feedback into account and introduce two categories of challenges; ”interpersonal” and ”intrapersonal”. We found no evidence for links between human values and challenges. We found some significant links between the number of distinct nationalities in a team and certain challenges, with less frequent and critical challenges occurring if 2-3 different nationalities were present compared to a team having members of just one nationality or more than three. A higher degree of virtualization seems to increase the frequency of some human challenges, which warrants further research about how to improve working processes when teams work from remote or in a distributed fashion.Conclusion:We present a set of human challenges in software engineering that can be used for further research on causes and mitigation measures, which serves as our starting point for a theory about causes of contemporary human challenges in software engineering teams. We report on evidence that a higher degree of virtualization of teams leads to an increase of certain challenges. This warrants further research to gather more evidence and test countermeasures, such as whether the employment of virtual reality software incorporating facial expressions and movements can help establish a less detached way of communication.

Full research paper-In this work, we study productivity differences in an introductory programming course. Focusing on a set of students who completed all programming assignments in the course, we quantify differences in productivity, measured through the time spent on completing the assignments. We focus both on the overall time needed to complete all programming assignments in the course, as well as on time spent on individual programming assignments. In addition, the effect of previous programming experience and difficulty of the programming assignment is considered. Our results show significant productivity differences between students. In addition, while programming experience influences productivity, a proportion of students who have never programmed before are faster in completing the programming assignments than students with considerable amounts of previous programming experience. Our results suggest that the classic credit-based or lecture hour based workload estimates of a course fit poorly to the whole course population in programming, suggesting that programming courses and training should be adjusted based on the participant.

Experiments are often used as a means to continuously validate user needs and to aid in making software development decisions. Involving users in the development of software products benefits both the users and companies. How software companies efficiently involve users in both general development and in experiments remains unclear; however, it is especially important to determine the perceptions and attitudes held by practitioners in different roles in these companies. We seek to: 1) explore how software companies involve users in software development and experimentation; 2) understand how developer, manager and UX designer roles perceive and involve users in experimentation; and 3) uncover systematic patterns in practitioners’ views on user involvement in experimentation. The study aims to reveal behaviors and perceptions that could support or undermine experiment-driven development, point out what skills could enhance experiment-driven development, and raise awareness of such issues for companies that wish to adopt experiment-driven development. We conducted a survey within four Nordic software companies, inviting practitioners in three major roles: developers, managers, and UX designers. We asked the respondents to indicate how they involve users in their job function, as well as their perspectives regarding software experiments and ethics. We identified six patterns describing experimentation and user involvement. For instance, managers were associated with a cautious user notification policy, that is, to always let users know of an experiment they are subject to, and they also believe that users have to be convinced before taking part in experiments. We discovered that, due to lack of clear processes for involving users and the lack of a common understanding of ethics in experimentation, practitioners tend to rationalize their perceptions based on their own experiences. Our patterns were based on empirical evidence and they can be evaluated in different populations and contexts.

A large dataset that contains the eye movements of N=216 programmers of different experience levels captured during two code comprehension tasks is presented. Data are grouped in terms of programming expertise (from none to high) and other demographic descriptors. Data were collected through an international collaborative effort that involved eleven research teams across eight countries on four continents. The same eye tracking apparatus and software was used for the data collection. The Eye Movements in Programming (EMIP) dataset is freely available for download. The varied metadata in the EMIP dataset provides fertile ground for the analysis of gaze behavior and may be used to make novel insights about code comprehension.

Background: Many decisions made in Software Engineering practices are intertemporal choices: trade-offs in time between closer options with potential short-term benefit and future options with potential long-term benefit. However, how software professionals make intertemporal decisions is not well understood. Aim: This paper investigates how shifting time frames influence preferences in software projects in relation to purposefully selected background factors. Method: We investigate temporal discounting by replicating a questionnaire-based observational study. The replication uses a changed-population and -experimenter design to increase the internal and external validity of the original results. Results: The results of this study confirm the occurrence of temporal discounting in samples of both professional and student participants from different countries and demonstrate strong variance in discounting between study participants. We found that professional experience influenced discounting. Participants with broader professional experience exhibited less discounting than those with narrower experience. Conclusions: The results provide strong empirical support for the relevance and importance of temporal discounting in SE and the urgency of targeted interdisciplinary research to explore the underlying mechanisms and their theoretical and practical implications. The results suggest that technical debt management could be improved by increasing the breadth of experience available for critical decisions with long-term impact. In addition, the present study provides a methodological basis for replicating temporal discounting studies in software engineering.

Technical Debt management decisions always imply a trade-off among outcomes at different points in time. In such intertemporal choices, distant outcomes are often valued lower than close ones, a phenomenon known as temporal discounting. Technical Debt research largely develops prescriptive approaches for how software engineers should make such decisions. Few have studied how they actually make them. This leaves open central questions about how software practitioners make decisions. This paper investigates how software practitioners discount uncertain future outcomes and whether they exhibit temporal discounting. We adopt experimental methods from intertemporal choice, an active area of research. We administered an online questionnaire to 33 developers from two companies in which we presented choices between developing a feature and making a longer-term investment in architecture. The results show wide-spread temporal discounting with notable differences in individual behavior. The results are consistent with similar studies in consumer behavior and raise a number of questions about the causal factors that influence temporal discounting in software engineering. As the first empirical study on intertemporal choice in SE, the paper establishes an empirical basis for understanding how software developers approach intertemporal choice and provides a blueprint for future studies.

Today’s students are prospective entrepreneurs, as well as potential employees in modern, start-up-like intrapreneurship environments within established companies. In these settings, software development projects face extreme requirements in terms of innovation and attractiveness of the end-product. They also suffer severe consequences of failure such as termination of the development effort and bankruptcy. As the abilities needed in start-ups are not among those traditionally taught in universities, new knowledge and skills are required to prepare students for the volatile environment that new market entrants face. This article reports experiences gained during seven years of teaching start-up knowledge and skills in a higher-education institution. Using a design-based research approach, we have developed the Software Factory, an educational environment for experiential, project-based learning. We offer a collection of patterns and anti-patterns that help educational institutions to design, implement and operate physical environments, curricula and teaching materials, and to plan interventions that may be required for project-based start-up education.

The growing literature on affect among software developers mostly reports on the linkage between happiness, software quality, and developer productivity. Understanding happiness and unhappiness in all its components – positive and negative emotions and moods – is an attractive and important endeavor. Scholars in industrial and organizational psychology have suggested that understanding happiness and unhappiness could lead to cost-effective ways of enhancing working conditions, job performance, and to limiting the occurrence of psychological disorders. Our comprehension of the consequences of (un)happiness among developers is still too shallow, being mainly expressed in terms of development productivity and software quality. In this paper, we study what happens when developers are happy and unhappy while developing software. Qualitative data analysis of responses given by 317 questionnaire participants identified 42 consequences of unhappiness and 32 of happiness. We found consequences of happiness and unhappiness that are beneficial and detrimental for developers’ mental well-being, the software development process, and the produced artifacts. Our classification scheme, available as open data enables new happiness research opportunities of cause-effect type, and it can act as a guideline for practitioners for identifying damaging effects of unhappiness and for fostering happiness on the job.

The happy-productive worker thesis states that happy workers are more productive. Recent research in software engineering supports the thesis, and the ideal of flourishing happiness among software developers is often expressed among industry practitioners. However, the literature suggests that a cost-effective way to foster happiness and productivity among workers could be to limit unhappiness. Psychological disorders such as job burnout and anxiety could also be reduced by limiting the negative experiences of software developers. Simultaneously, a baseline assessment of (un)happiness and knowledge about how developers experience it are missing. In this paper, we broaden the understanding of unhappiness among software developers in terms of (1) the software developer population distribution of (un)happiness, and (2) the causes of unhappiness while developing software. We conducted a large-scale quantitative and qualitative survey, incorporating a psychometrically validated instrument for measuring (un)happiness, with 2 220 developers, yielding a rich and balanced sample of 1318 complete responses. Our results indicate that software developers are a slightly happy population, but the need for limiting the unhappiness of developers remains. We also identified 219 factors representing causes of unhappiness while developing software. Our results, which are available as open data, can act as guidelines for practitioners in management positions and developers in general for fostering happiness on the job. We suggest considering happiness in future studies of both human and technical aspects in software engineering.

Background: Experiment-driven development with the help of real usage data helps to build software products and services that are of high value to their users. As more software companies use experimentation in their development practises, ethical concerns are increasingly important. Objective: There is a need for understanding the ethical issues companies must take into account when practising experimentation as a development strategy. This paper examines how software development practitioners experience the need for notifying users when involving them in experimentation. Method: We conducted a survey within four software companies, inviting employees in different functional roles to indicate their attitudes and perceptions through a number of statements. Results: Employees working in different roles have different viewpoints on ethical issues. While managers are more conscious about company-customer relationships, UX designers appear more familiar with involving users. Developers think that details of experiments can be withheld from users if the results depend on it. Conclusion: Barriers to successfully conducting experiment-driven development are different for different roles. Clear and specific guidelines are needed for ethical aspects of experimentation.

Today's students are prospective entrepreneurs and employees in modern, start-up like environments within established companies. In these settings, software development projects face extreme requirements in terms of innovation and attractiveness of the end-product. They also suffer severe consequences of failure such as termination of the development effort and bankruptcy. As the abilities needed in start-ups are not among those traditionally taught in universities, new knowledge and skills are required to prepare students for the volatile environment that new market entrants face. This paper reports experiences gained during seven years of teaching start-up knowledge and skills in a higher-education institution. We offer a collection of patterns that help educational institutions to design, implement and operate physical environments, curricula and teaching materials, and to plan interventions that may be required for project-based start-up education.

Open Source Software developer communities are susceptible to challenges related to volatility, distributed coordination and the interplay between commercial and ideological interests. Here, community managers play a vital role in growing, shepherding, and coordinating the developers' work. This study investigates the varied tasks that community managers perform to ensure the health and vitality of their communities. We describe the challenges managers face while directing the community and seeking support for their work from the analysis tools provided by state-of-the-art software platforms. Our results describe seven roles that community managers may play, highlighting the versatile and people-centric nature of the community manager's work. Managers experience hardship of connecting their goals, questions and metrics that define a community's health and effects of their actions. Our results voice common concerns among community managers, and can be used to help them structure the management activity and to find a theoretical frame for further research on how health of developer communities could be understood.

Software developers are both users of development tools but also designers of new software systems. This dual role makes developers special users of work-related software. To increase the understanding of developers as users and to evaluate the ability of common measurement scales to address developer experience, we conducted a survey measuring developers’ flow state, intrinsic motivation and user experience. Scales used were the Short Dispositional Flow Scale, items from the Intrinsic Motivation Inventory, the Short AttrakDiff-2, and our own DEXI scale. 57 developers from 25 countries responded and results indicate that intrinsic motivation and autotelic experience are significant predictors of developers’ UX whereas hedonic, pragmatic, and general quality are not. In addition, developers’ needs are characterized by efficiency, informativeness, intuitiveness, and flexibility of the tool.

Managers recognize that software development project teams need to be developed and guided.Although technical skills are necessary, non-technical (NT) skills are equally, if not more, necessary for project success.Currently, there are no proven tools to measure the NT skills of software developers or software development teams.Behavioral markers (observable behaviors that have positive or negative impacts on individual or team performance) are beginning to be successfully used by airline and medical industries to measure NT skill performance.The purpose of this research is to develop and validate the behavior marker system tool that can be used by different managers or coaches to measure the NT skills of software development individuals and teams.This paper presents an empirical study conducted at the Software Factory where users of the behavior marker tool rated video clips of software development teams.The initial results show that the behavior marker tool can be reliably used with minimal training.

Managers recognize that software development teams need to be developed. Although technical skills are necessary, non-technical (NT) skills are equally, if not more, necessary for project success. Currently, there are no proven tools to measure the NT skills of software developers or software development teams. Behavioral markers (observable behaviors that have positive or negative impacts on individual or team performance) are successfully used by airline and medical industries to measure NT skill performance. This research developed and validated a behavior marker system through an empirical study conducted at the Software Factory where users of the behavior marker tool rated video clips of software development teams. The initial results show that the behavior marker tool can be reliably used with minimal training.

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 categories 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.

Context: Onboarding is a process that helps newcomers become integrated members of their organisation. Successful onboarding programs can result in increased performance in conventional organisations, but there is little guidance on how to onboard new developers in Open Source Software (OSS) projects. Goal: In this study, we examine how mentoring and project characteristics influence the effectiveness and efficiency of the onboarding process. We study a collaboration program involving a total of nine Open Source Software projects and more than 120 students from different universities around the world as part of Facebook's Education Modernization Program. Method: We use quantitative measurements of source code repositories, issue tracking systems, and discussion fora to examine how newcomers become contributing members of their OSS projects. Results: We found that developers receiving deliberate onboarding support through mentoring were more active at an earlier stage than developers entering projects through conventional means. Also, we found that project size and lifetime influenced onboarding. Conclusion: Empirical decision support can contribute to a more effective onboarding process in OSS projects. Mentor support in critical stages can accelerate the process, but project maturity is also a significant factor that increases the effect of onboarding.

To prepare students for real-life software engineering projects, many higher-education institutions offer courses that simulate working life to varying degrees. As software engineering requires not only technical, but also inter- and intrapersonal skills, these skills should also be assessed. Assessing soft skills is challenging, especially when project-based and experiential learning are the primary pedagogical approaches. Previous work suggests that including students in the assessment process can yield a more complete picture of student performance. This paper presents experiences with developing and using a peer assessment framework that provides a 360-degree view on students' project performance. Our framework has been explicitly constructed to accommodate and evaluate tacit skills that are relevant in agile software development. The framework has been evaluated with 18 bachelors- and 11 masters-level capstone projects, totaling 176 students working in self-organized teams. We found that the framework eases teacher workload and allows a more thorough assessment of students' skills. We suggest including self- and peer assessment into software capstone projects alongside other, more traditional schemes like productivity metrics, and discuss challenges and opportunities in defining learning goals for tacit and social skills.

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 concept that captures how persons feel about products, systems and services. It evolved from disciplines such as interaction design and usability to a much richer scope that includes feelings, motivations, and satisfaction. Similarly, developer experience could be defined as a means for capturing how developers think and feel about their activities within their working environments, with the assumption that an improvement of the developer experience has positive impacts on characteristics such as sustained team and project performance. This article motivates the importance of developer experience, sketches related approaches from other domains, proposes a definition of developer experience that is derived from similar concepts in other domains, describes an ongoing empirical study to better understand developer experience, and finally gives an outlook on planned future research activities.

The pertinent mission of software project management is to continuously achieve more and more successful projects. In the field of software development, the Kanban method has gained momentum recently, mostly due to its linkages to Lean thinking. However, only a few empirical studies investigate the dynamics and impacts of Kanban on projects. The aim of this study is to improve the understanding on how Kanban impacts on software project work. For the purpose of the study, a framework is developed and empirically investigated in an experimental software R&D setting called Software Factory. The impact of Kanban is evaluated from nine theoretically derived perspectives. The results highlight new findings regarding the application of Kanban in the software context. This bears managerial implications, which is addressed. The key implications of the findings suggest that Kanban and its inherent simplicity motivate the workers and control the project activities.