Intersectional Software Engineering as a Field

Abstract

Intersectionality is a concept used to explain the power dynamics and inequalities that some groups experience owing to the interconnection of social differences such as in gender, sexual identity, poverty status, race, geographic location, disability, and education. The relation between software engineering, feminism, and intersectionality has been addressed by some studies thus far, but it has never been codified before. In this paper, we employ the commonly used ABC Framework for empirical software engineering to show the contributions of intersectional software engineering (ISE) as a field of software engineering. In addition, we highlight the power dynamic, unique to ISE studies, and define gender-forward intersectionality as a way to use gender as a starting point to identify and examine inequalities and discrimination. We show that ISE is a field of study in software engineering that uses gender-forward intersectionality to produce knowledge about power dynamics in software engineering in its specific domains and environments. Employing empirical software engineering research strategies, we explain the importance of recognizing and evaluating ISE through four dimensions of dynamics, which are people, processes, products, and policies. Beginning with a set of 10 seminal papers that enable us to define the initial concepts and the query for the systematic mapping study, we conduct a systematic mapping study leads to a dataset of 140 primary papers, of which 15 are chosen as example papers. We apply the principles of ISE to these example papers to show how the field functions. Finally, we conclude the paper by advocating the recognition of ISE as a specialized field of study in software engineering.

1. Introduction

Intersectional software engineering (ISE) is a field of study that examines power imbalances, hierarchies, and biases throughout the software engineering pipeline and across product and design life cycles. While ISE work has been practiced since the 1990s, the field itself is not yet formalized. This is in part because of the erasure of women from the history of computing [1], closing the field through undergraduate barriers [2], and devaluing the importance of social topics in software engineering (see Dijkstra 73, 75 in [3]). Not acknowledging ISE as a field is also partly caused by political reactions to diverse voices reclaiming their spaces in the design, development, and deployment of technology. However, in the nearly 30 years of the field, notable contributions of ISE to software engineering include topics like community smells, the bias detector GenderMag, open source community policy and guideline analysis, and gender balance in informatics research. In addition, there have been renewed calls in recent years for ISE like creating a feminist programming language [3], fairness in software engineering [4], feminist AI [5,6], and data feminism in NLP [7]. All of these calls are examples of future intersectional software engineering research.

ISE has its roots in empirical software engineering, so the field is based on evidence-based practice, blending both the social and technical aspects of software engineering across a wide range of topics. Several papers hold high importance for modern empirical software engineering, such as Sjøberg et al.’s survey of empirical controlled experiments [8], Carver et al.’s [9] checklist for translating the evidence of empirical software engineering studies into the classroom, and Wohlin’s [10] exploration of evidence profiles in software engineering. These works prioritize and showcase the need for evidence-based practice, as well as demonstrate how to use it through the presentation of specific methods and design. Fernández and Passoth’s [11] exploration of interdisciplinarity in software engineering presents the pragmatic cycle for empirical software engineering and calls into question the weak state of empirical evidence for the choices made in software engineering and development. Among other things, Fernandez and Passoth point out the need for increased collaborations and a focus on human-centric challenges. Their call also encourages empirical software engineering researchers to become aware of and address new challenges. ISE has been bridging these gaps in collaboration, human-centric research, and raising awareness of and addressing new social challenges, both in the classroom and through empirical studies.

The ABC Framework [12,13], shown in Figure 1, describes and contextualizes research strategies and is valuable for providing guidelines for understanding studies. Stol and Fitzgerald based the ABC Framework on principles from social psychology and the emerging applications of the ABC framework in software engineering at the time. This framework places eight types of empirical research strategies for knowledge-seeking into quadrants and identifies relevant constructs based on their obtrusiveness and generalizability, along with three main components to empirical software engineering research. They are actors (A), behavior (B), and context (C). The ABC framework is generally useful for the evaluation of studies and understanding and developing data collection/generation methods and design, but this framework was validated by showing how studies in global software engineering and requirements engineering apply the research strategies and ABC classifications. In our study, we apply the ABC framework to a dataset of 140 studies to identify the contributions of intersectional software engineering and the additional dimension of power dynamics, a defining component of ISE research. We also show ISE as a field of study that applies intersectional analysis or gender-forward intersectionality (defined as using gender as a starting point to identify and/or analyze other aspects of systemic bias). We identify the main guiding principles extrapolated from the dataset using several rounds of thematic coding. Finally, we identify the themes of intersectional software engineering research that are most often explored, the design of research inquiries, and ISE contributions to software engineering.

1.1. Intersectional Traits and Software Engineering: State of the Art

Intersectionality in software engineering primarily focuses on tools developed to enhance learning. These tools can be designed to improve creative thinking (e.g., [14]), assistive technologies (e.g., [15]), or motivation and interest in STEM in general (e.g., [16]) in primary and secondary education. Few studies address diversity and inclusion in software engineering education in university settings (e.g., [17,18,19,20]). Of these, Groher et al. [17] addresses gender and other diversity dimensions in university classrooms by identifying a clear gender gap both in exam scores and dropout rate. Our study defines gender-forward intersectionality and highlights how it is employed in ISE. We also direct to guidelines [21] for designing intersectional studies in ISE. Here, we present a history of using gender as a starting point to identify or address other gaps in diversity, equity, and inclusion in software engineering.

Historically, computer science was female-led, and females continue to innovate across the landscape. Intersectional traits have had a presence in computing through social informatics and science and technology studies. In 2010, studying and designing with a gender-informed lens became semi-formalized with feminist human–computer interaction (HCI) [22]. Feminist HCI designs technology-enabled products that address women as users and consumers of products [23]. As a research area, feminist HCI initiated a theoretical agenda [24] focused on the design of technology that addresses women’s needs and experiences, emphasizing user-centered design and the inclusion of diverse perspectives in the design process. This is achieved by identifying the users, producers, and organizers in the design and life cycle of a product or tool [25] to create more inclusive and equitable user experiences by bringing gender back into the discussion and design [24,26,27]. The field has also taken to expressing how HCI can address ecological issues [28,29,30], incorporate care into design [31], learn from social movements [32,33], and how to reconcile past endeavors with new interests in the field [34]. Feminist data visualization [35,36,37,38] builds on this tradition of advancing theory, methodology, design, and user research.

Data feminism builds on feminist HCI and data visualization to provide feminist principles and merge them with data science [39,40] focusing on ethical data practices, inclusivity, and the rectification of biases and power imbalances in technology and data analysis. It emphasizes principles such as examining and challenging power, elevating emotion and embodiment, rethinking binaries and hierarchies, embracing pluralism, considering context, and making labor visible. The goal is to create an agenda based on pluralism and thoughtful design to develop theory, methodology, and evaluation through user research. Data feminism is the evolution of what came before, coalesced into seven guiding principles. D’Ignazio and Klein identified working with communities to identify needs and solutions using data science. The principles of data feminism are:

• Examine power;
• Challenge power;
• Elevate emotion and embodiment;
• Rethink binaries and hierarchies;
• Embrace pluralism;
• Consider context;
• Make labor visible.

These principles act as guidelines for making data equitable.

ISE adapts the feminist traditions in computing that have come before: the focus on gender and the need to incorporate women throughout the process of software engineering comes from feminist HCI. The guiding principles of data feminism are adapted for application to the diverse, rich settings and contexts of software engineering. These traditions are highlighted in the scope and boundaries of the ISE field. We also show, through an analysis of software engineering topics, that ISE is an umbrella like most software engineering fields, that incorporates a variety of topics.

In addition, Turcios et al. [21] identify the tasks intersectional research in machine learning should perform. The authors identify five guidelines and their criteria through a systematic literature review. They also present a critical evaluation of intersectionality in practice in three case studies in machine learning papers that claim to be intersectional. The identified guidelines are:

• Intersectionality as a relational analysis;
• Social formations of complex social inequalities;
• Historical and cultural specificity;
• Feature engineering and statistical methods;
• Ethical considerations and transparency (p. 4).

These guidelines serve to further highlight power dynamics and imbalances in existing literature in addition to design better research studies that employ intersectionality in software engineering. This study is an example of ISE research, and it provides a set of guidelines for thoughtfully conducting research that calls itself intersectional.

Despite the contributions of these fields, there is a need to establish ISE as a specialized field within software engineering that is distinct from feminist HCI and data feminism. We clearly show that intersectional software engineering is not just a lens for reviewing previously conducted research. Instead, it is a thriving and growing discipline in which power is investigated through interconnected characteristics. Gender-forward intersectionality serves to explore additional areas of inclusion, equity, and diversity as well as the impacts power imbalances have on software systems and processes. These characteristics were unexpectedly universal across our dataset and are codified as the principles that define ISE. We present the existing datasets and tools that are ISE products as well as the methods most commonly used in the ISE dataset. We acknowledge that the intersectional guidelines from Turcuios et al. are a powerful framework for intersectionality studies, and it is not included in the dataset because it was published outside the scope of data collection and analysis. However, these guidelines address, through the framework of intersectionality, ISE, gender biases, and inclusivity within the software engineering discipline.

1.2. Motivation

The recognition of ISE as a specialized field of study is crucial for several reasons, extending beyond academic interest into the practical realms of software development and societal equity. This specialized field of study aims to address and rectify the systemic biases and inequalities that have long plagued the software engineering field [41,42,43,44]. By formally establishing ISE as a field of research, we can significantly improve the methods and tools used for the specification, design, development, and maintenance of software systems, while also fostering a more inclusive and equitable environment for all practitioners. We believe that ISE contributes to improving software engineering, both in education and industry, in the following ways:

• Enhancing methods and tools in software engineering
  • Bias-aware software development: Traditional software engineering methods often overlook the diverse needs and perspectives of underrepresented groups, such as women. ISE will facilitate the creation of frameworks and methodologies that actively identify and mitigate biases in software design and development processes, thereby leading to the creation of more inclusive and user-friendly software products that cater to a broader audience (e.g., [45,46,47]).
  • Innovative research approaches: By integrating feminist theories [22,29,35,48] and intersectionality [49,50,51,52,53] into software engineering research, ISE encourages the development of innovative approaches that challenge the status quo. This includes new ways of thinking about problem solving, team dynamics, and user interactions that may lead to more robust and adaptable software solutions (e.g., [54]).
  • Comprehensive evaluation metrics: ISE advocates the use of comprehensive evaluation metrics that consider the social and ethical implications of software systems [21,39,55,56,57,58] This approach ensures that the software not only meets technical requirements but also promotes application fairness and equity.
• Achieving equity in software engineering
  • Attracting female researchers and professionals to industry: The formal recognition of ISE as a research field can help attract more female researchers to software engineering. By highlighting the importance of gender and intersectionality in software development, ISE will set the stage for a more welcoming and supportive environment for women and other marginalized groups. This can lead to increased research team diversity, which has been shown to enhance creativity and innovation [59,60].
  • Equal pay and career advancement: ISE addresses the systemic issues that contribute to the gender pay gap and the underrepresentation of women in leadership positions. By promoting policies and practices that ensure equal pay for equal work and providing support for equality in career advancement, ISE helps create a more equitable workplace where all individuals can succeed [61,62].
  • Improving perceptions of female researchers: The establishment of ISE as a recognized field of study helps to challenge and change the negative stereotypes and biases that often affect female researchers in associated fields. By showcasing the valuable contributions of women in software engineering and emphasizing the importance of diverse perspectives, ISE can improve the perception of female researchers and encourage more women to pursue careers in this field [63,64,65,66,67].

In summary, the recognition of ISE as a specialized field of study is not only essential for advancing the field of software engineering but also for promoting equity and inclusivity within related professions. By addressing the unique challenges faced by underrepresented groups and fostering a more diverse and supportive environment, ISE can lead to significant improvements in both software system quality and the experiences of those who develop them.

1.3. Summary of Key Contributions

A summary of the contributions of our study are presented herein:

• We define gender-forward intersectionality, a theoretical principle of ISE research.
• We define ISE as a distinct field of study;
• We introduce the principles and applications of ISE;
• We conduct a systematic mapping study that identifies and analyzes a comprehensive set of 140 ISE papers;
• We present the common research investigations in the field;
• We evaluate the principles and applications of ISE through an analysis of fifteen published empirical studies.

1.4. Structure of the Paper

The rest of this paper is organized as follows. Section 2 presents information about the problems addressed by ISE, as well as highlighting intersectionality, representation, feminist traditions in data science and HCI methodology, and an overview of empirical methods in software engineering research. Section 3 addresses the methodology used to identify the ISE field, define it, and present its principles and describes the applications of ISE in software engineering research. Section 4 presents the definitions, principles, and cases. Finally, Section 5 discusses the contributions to society and relevance of recognizing ISE as a specialized field of study in software engineering.

2. Background and Related Work

Many fields of research consider and prioritize gender in different ways. While researchers acknowledge that there are more than two genders [68] and that gender is a spectrum [69], few studies in empirical software engineering present gender as extending beyond the traditional binary classification (e.g., [70,71,72]). This is particularly in the classroom (e.g., [73,74,75,76,77]). Promoting the notion of the existence of a range of gender dimensions ensures that biological characteristics, social and cultural features, and the behaviors and needs of different groups are properly considered in and across contexts and settings [78,79,80,81]. Gender research focuses on examining at least one aspect of the gender gap, this term referring here to the relative disparity between people of different genders (See: https://www3.weforum.org/docs (accessed on 10 April 2024)).

2.1. Problems with Gender in Software Engineering

Gender is still recognized as binary in international organizations and in many countries as reflected in statistical data. While the researchers acknowledge that gender is a spectrum that includes trans- (e.g., [82,83]), gender-neutral, and non-binary people [84], this subsection focuses on research performed in the gender binary. Despite many efforts at the international and European levels to address the gender gap between women and men in employment, women accounted for only 15.6% of the total number of employed persons in the European Union (See: https://ec.europa.eu/eurostat/web/products-eurostat-news/w/ddn-20231016-1 (accessed on 10 April 2024)) with an information communication technology education in 2022. This is a reduction of 1.6% from 2016 figures [85].

If we consider the social and economic perspectives, ensuring gender balance in software engineering becomes of the utmost importance. For example, the European Commission’s report Women Active in the ICT Sector [86] concluded that including more women in the digital economy could create an annual gross domestic product boost in social inclusion and gender balance. Established by the United Nations, Sustainable Development Goal 5 (See: https://sdgs.un.org/goals/goal5 (accessed on 10 April 2024)) focuses on gender equality and the empowerment of all women and girls. This ambitious goal emphasizes social freedoms and rights and policies and laws like achieving parity in the workplace for women and men, including in leadership positions, by the year 2030. While society is nowhere near achieving the Sustainable Development Goal 5 targets, some researchers in data feminism (e.g., [6,39,40]), software engineering (e.g., [87,88]), and artificial intelligence (e.g., [50,89,90]) are highlighting the challenges women face in teams, education, product design, and the workplace.

Diversity and inclusion in software engineering can make an impact in the products that are developed and released for use in business, education, and society. For instance, Ahmed et al. [45] show that using datasets that contain under-representation of gender and other marginalized traits further amplifies bias, both in the product and in society. As Takaoka and Jaccheri [91] point out, women are often omitted from the design, development, testing, and deployment processes of software engineering, and in many cases, the likenesses of women are often omitted altogether. This is only one reason why women need to be software engineers.

2.2. The Gender Gap in Software Engineering

Software engineering (SE) began with women, and the name was created by Margaret Hamilton, American computer scientist, systems engineer, and business owner. Hamilton was the Director of MIT’s Instrumentation Laboratory, which developed onboard flight software for NASA’s Apollo program. In the late 1960s, Hamilton began using the term “software engineering… to distinguish it from hardware and other kinds of engineering, yet treat each type of engineering as part of the overall systems engineering process” [92]. She was not alone; other computing pioneers included the female computing pioneers named Ada Lovelace, Grace Hopper, Evelyn Boyd Granville, Katherine Johnson, Hedy Lamarr, and Annie Easley, along with so many others [93].

The number of women in software engineering has diminished from 37% in 1984 to just 27% in 2022. The effects of this lack of women in software engineering can be seen in the omission of women in generated images related to software engineering, where no prompts specify the inclusion of women [67]. One reason is that women are often left out of software design, development, creation, and testing processes, entailing that their likeness is often omitted by default [91]. Still, women of many ages and backgrounds want to learn tech [94], and having women in software engineering can reduce many issues associated with software production and maintenance. From a software engineering perspective, increasing the number of women on related teams reduces community smells [95,96], the latter term serving to “[…] describe connections between the poor socio-technical decisions that shape work environments and their adverse effects on individuals and software development teams” [95]. These community smells impact social debt, including project costs, software teams, processes, and organizations.

Even though research shows these economic and time-saving benefits, a gender gap remains in software engineering across different levels. More specifically, while a lack of exposure to coding in schools may be a reason for this gap (e.g., [83,97]), social perceptions about gender may also play an important role. The gender gap in software engineering persists in-part because of several social narratives [98]. These include stereotypes about women and software engineers. Many individuals still associate science and technology with masculine qualities, and these biases can discourage girls and women from pursuing education and careers in science and technology [99,100].

Narratives about software engineers both influence and are maintained by unconscious biases [101,102,103], with gender- and youth-related biases being good examples that often influence employee management, promotion, and retention, as well as further the disadvantages of women. Low representation [104,105] for women and people with other diverse traits [106] continues to have lasting effects [107,108], and highlight a lack of role models. Women remain underrepresented in leadership positions, making it harder for girls and women to find role models and mentors in the field [109]. It is also a reality that careers can be unnecessarily demanding [88,110], and some women may opt out or choose to work part-time to handle family responsibilities, which are choices that can negatively impact anyone’s career advancement [111,112], but particularly impact women.

As expressed by Ozkaya [113], it can be challenging to identify issues in gender balance until they are pointed out. Many women in leadership, do not covet power, but instead wonder where all the women are. This juxtaposition draws attention to the possibility of recruiting and promoting women in academia from PhD to a tenured position and eventually into leadership. Attention is also drawn to the need for female role models in software engineering.

Stereotypes and lack of role models in software engineering create a feedback loop not only in the people interested and working in software engineering but also in the maintenance and reinforcement of biases in training models and datasets for AI, algorithms, and autonomous systems [114,115,116]. Nowhere has this become clearer than with the careless deployment of generative artificial intelligence for public use, indicating the need for intersectional research in software engineering education, products, and team dynamics.

2.3. Intersectionality

Intersectionality, first defined by Crenshaw in 1989 [49], is the idea that people are judged on more than just one character trait in isolation. Instead, all of the unique traits that make a person shape their experiences and the biases and stereotypes held against them. Crenshaw writes, “…multiple forms of inequality or disadvantage sometimes compound themselves and create obstacles that often are not understood among conventional ways of thinking” [49]. This includes visible traits like race, physical disabilities, and gender presentation, and invisible traits like concealable stigmas. Invisible traits are social stigmas carried inside a person and not being discernible unless they are voluntarily disclosed [117]. These include sexual orientation [118] and mental illnesses [119,120]. The recognition of diversity and inclusion in software engineering teams [121] can have a profound impact on the world we live in—and at a global scale. Figure 2, adapted by the United Nations and presented in the Intersectionality Resource Guide and Toolkit shows a set of intersectional traits and biases, areas of potential intersections between different concealable biases that may contribute to inequality and disadvantages.

Currently, there is a lack of research using the term intersectionality in software engineering (e.g., [122,123,124]), mostly due to obstacles in researching multiple levels of diversity between software engineering stakeholders. However, it is possible to recognize multiple empirical research that aims to investigate how important factors such as age, race, sexual orientation, education, and so on act as additional barriers for non-male subjects (e.g., [80,91,125,126,127]). Therefore, we have defined gender-forward intersectionality to describe research in software engineering that is intersectional without calling itself intersectional.

2.4. Representation and Gender in the Classroom

Many long-standing initiatives exist to promote equity in faculty recruitment in the STEM fields [128] like software engineering and software entrepreneurship [129], but representation by women and other disenfranchised groups remains low in the fields (e.g., [130,131,132]). Furthermore, gatekeeping by faculty on hiring committees still include unnecessarily exclusionary criteria, like venues of publication, that continue to promote a homogeneous work environment [133]. Most research about hiring diverse faculty focuses on employer concerns; however, research on the benefits of a diverse workplace has started to emerge [134]. Students have noticed the differences that such emergence has brought to the classroom.

One way to cultivate a more balanced software engineering workforce is designing gender-neutral classrooms [83], but faculty representation may also play a role because how faculty teach and engage with software engineering students matters [135]. Having role models and mentors that look like us makes a difference, but collectively, we are starting to understand that stigmatized traits, both visible and concealable, are valued as well [136,137]. For example, how faculty perceive their gender identity has been shown to also shape classroom dynamics and interactions with students [111,138]. Being able to prioritize personal experience as a valued source of information helps marginalized individuals feel seen and supported [112], and these types of information have value in software engineering methods and research [40] as well as on computing careers. Therefore, integrating ISE into the classroom can also influence the dynamics and interactions within such settings.

3. Methods

ISE advances the methods and quality of software engineering by critically examining imbalances and biases at key points in software design, development, and release, as well as addresses gender imbalances throughout the software engineering career (i.e., from education to career retention). Studies in ISE, like in global and requirements software engineering, offer recommendations, best practices, frameworks, and tools to address related issues and concerns. We discuss the process of identifying boundaries and contributions of the field through a systematic mapping study, as it is a common method for establishing fields of interest in software engineering [139]. All three researchers contributed to the methods and analysis process.

3.1. Identification of Seminal Papers

Through purposive sampling, a non-random form of sampling to highlight deliberate qualities [140], we identified ten seminal papers that are representational of the field based on our experiences with designing Bachelors and Masters level courses in gender and intersectionality for software engineering and conducting doctoral and post-doctoral research on the topic. This set of 10 seminal papers represent “key sources and […] indicate the range of variety in different methods that have been used in SE research” ([12], p. 11:7). Implementing thematic analysis through open and axial coding, two common and complimentary coding methods to identify broad themes and clusters in qualitative data [141], enabled us to design and test our search query, extrapolate the research dynamics, or areas of research, and identify the common research themes evaluated in ISE studies. The 10 seminal papers are shown in

Table 1. Seminal papers identified through purposive sampling used to design and test the search query and preliminary principles for ISE.

Seminal#	Cit.	Authors	Title	Year
S1	[142]	Blincoe et al.	Perceptions of gender diversity’s impact on mood in software development teams	2019
S2	[143]	Burnett et al.	GenderMag: A method for evaluating software’s gender inclusiveness	2016
S3	[96]	Catolino et al.	Gender diversity and women in software teams: How do they affect community smells?	2019
S4	[121]	Dagan et al.	Building and sustaining ethnically, racially, and gender diverse software engineering teams: A study at Google	2023
S5	[144]	Hilderbrand et al.	Engineering gender-inclusivity into software: Ten teams’ tales from the trenches	2020
S6	[145]	Kanij et al.	A new approach towards ensuring gender inclusive SE job advertisements	2022
S7	[146]	Silviera and Prikladnicki	A systematic mapping study of diversity in software engineering: A perspective from the agile methodologies	2019
S8	[147]	Singh et al.	Codes of conduct in open source software—for warm and fuzzy feelings or equality in community?	2021
S9	[148]	Trichenriech et al.	An empirical investigation on the challenges faced by women in the software industry: A case study	2022
S10	[149]	Vasilescu et al.	Gender and tenure diversity in GitHub teams	2015

.

3.2. Query

A simple query was designed to gather articles from ACM Digital Library, which includes top-tier software engineering journals like ACM Transactions on Software Engineering and Methodology (TOSEM), Automated Software Engineering (ASE), and others, IEEE, and Scopus, which includes top tier publishing venues for empirical software engineering including all of the ACM digital library journals. We conducted snowball sampling, a common technique for software engineering literature reviews for gathering new sources from references and citations [140] from citations and targeted publications based on our awareness of publication venues known for publishing ISE works. The query was [(gender OR wom OR girl) AND “software engineering”]. An additional search was conducted using the query [intersectionality AND “software engineering”]. While this search produced two results in ACM Digital Library and ten in IEEE, these sources already appeared in the results from the previous query. Data were primarily collected on 22 March 2024, with a follow-up in Scopus conducted on 12 December 2024.

The articles retrieved through the query were as follows:

• Scopus: 667
• ACM Digital Library: 20
• IEEE: 24

Snowball sampling for specific venues:

• International Conference on Software Engineering (ICSE): 527
• Gender Equity, Diversity, and Inclusion at ICSE (GE@ICSE): 36
• Software Engineering in Society (ICSE-SEIS): 18
• Foundations of Software Engineering (FSE): 91
• Journal of Systems and Software: 18
• Empirical Software Engineering: 20
• Open Source Systems Conference: 15
• QUATIC: 4
• HICSS: 92

It must be noted that a search was specifically conducted for the search terms in IEEE Transactions on Software Engineering (TSE) in the IEEE Xplore Digital Library and ACM Transactions on Software Engineering Methodology (TOSEM) and Automated Software Engineering (ASE) in the ACM Digital Library. These searches produced zero results.

3.3. Inclusion and Exclusion Criteria

A total of 1532 initial papers were retrieved. After identifying and removing duplicates and proceedings and edition titles, a filtering based on inclusion and exclusion criteria was applied. Articles were excluded if they did not meet the following criteria:

• At least one of the search query terms “gender, girl, or wom” is present in the title or abstract;
• Be written in English;
• Be about a topic relevant to software engineering;
• Search terms must be applicable and appropriate for ISE (e.g., gender is used to describe trans-folks or men and not to engender a thing);
• Search query term is analyzed, used to filter results, or presented as a construct;
• Must have keywords;
• Must be empirical;
• Must present both Methods and Results.

Page limits and word counts, which are common exclusion criteria for omitting papers in systematic literature reviews and systematic mapping studies, were not considered for this study. This is because these criteria limit emerging works, especially those presented as short papers and extended abstracts in workshops like GE@ICSE and doctoral symposia at conferences like the International Conference on Evaluation and Assessment in Software Engineering (EASE). After keyword classification, additional filtering was conducted based on identifying the power dynamics from ISE and the research strategy of each study (i.e., through analyzing the Abstract and Methods sections when necessary). This resulted in a set of 140 primary studies identified for mapping analysis.

3.4. Systematic Mapping Study

A systematic mapping study was conducted to identify relevant papers in the field of ISE. The systematic mapping consisted of five phases. In Phase 1, ten seminal papers were used to define and test our search query. Phase 2 saw the deployment of the search query in the ACM and IEEE digital libraries in March 2024. In addition, specific venues were targeted for snowball sampling. A follow up search was conducted in Scopus in December 2024. A review of all abstracts (n = 1532) was conducted after both search periods. In Phase 3, all titles and abstracts were screened in accordance with the inclusion and exclusion criteria, resulting in 142 relevant papers. Phase 4 consisted of coding abstracts and keywords using open coding, a first cycle coding strategy to identify emerging concepts, and axial coding, an organizational type of coding to identify dimensions of constructs, followed by pattern coding, a second-cycle coding method used to identify similarly coded data and generate themes [150]. A classification scheme was developed. Two papers were removed at this phase because they lacked keywords (n = 140). This set of 140 papers is the dataset, and throughout this work, they are referred to as our primary studies. We mapped these 140 papers in the dataset to the ABC framework. Finally in Phase 5, data were extracted to identify the principles and research boundaries of ISE as a field of study. Systematic maps were constructed, the definitions and principles were tested, and the classification was conducted. This phase also resulted in the identification of our 15 example cases. An overview of the process is shown in Figure 3.

3.5. Dataset Analysis

The dataset consists of 140 initial papers published in conference proceedings and academic journals. To identify relevant aspects of the field of ISE, we performed several types of thematic analysis using a staged approach including structural coding to identify bibliographic information relevant for the systematic mapping of the dataset. To identify the themes most often researched in the dataset, a keyword classification was performed. Focused coding, the analysis step for identifying the themes that emerged from the previous coding strategies [150], was conducted to identify the research themes and emergent investigations in the ISE field. This analytical methodology allowed us to construct the guiding principles, dynamics, and definitions of the ISE field. Once these principles and definitions were developed, structural coding, categorizing, and describing data based on specific attributes like methodology or actor [141], were performed to test the applicability and accuracy of the principles. In conducting this multi-round coding approach, the main thematic areas of each study were identified. These were then coalesced into keyword classifications that represent the current topics studied in the field of ISE.

3.6. Example Case Analysis

Upon completion of structural coding for the 140 primary studies, purposive selection of a set of fifteen cases, each exemplifying a topic, which we call a keyword, were identified. A selected case had to meaningfully represent a power dimension and not be redundant. The identified case studies underwent thematic analysis using structural and attribute coding to identify each of the following elements: a brief summary, each ISE principle (P1–P4), and the quadrant and research strategy it represents.

3.7. Extraction of Tools, Datasets, and Methods in Intersectional Software Engineering Research

The tools, datasets, and methods mentioned in the dataset are extracted in order to compile a growing body of useful research aids used in ISE. The links for tools and datasets were identified either directly in the sources themselves or through online investigation. The methods were categorized into frameworks, methods of data collection/generation, or analysis. Upon completion of a structural coding process for the 140 primary studies, attribute coding was performed. More specifically, the identified empirical studies underwent thematic analysis using to identify each of the following elements: any relevant datasets or tools mentioned as well as their methods for data collection analysis, and any methodological frameworks employed in the study design.

4. The Mapping of ISE

In this section, we present the findings from the systematic mapping study. We present the mapping and classification of intersectional software engineering studies, found using open and axial coding. We then define gender-forward intersectionality and intersectional software engineering from pattern coding and identify the principles using focused coding. Finally, we apply the principles using structured coding. Additionally, we introduce a preliminary collection of tools and datasets used in ISE research.

4.1. Mapping and Classification of the Primary Studies

The 140 primary studies were mapped in alignment with bibliographic information like the year published, venue published, total articles by authors published. The articles published by year is shown in Figure 4. In the dataset, 2019 saw 24 primary studies, or 17.1%, published in ISE. This is followed by 23 studies, or 16.4%, in 2024. The top venues for publishing ISE articles include eight conferences and three journals. Of the eight conferences, 36% are associated with the International Conference of Software Engineering (ICSE), including the main track, GE@ICSE, Software Engineering in Society, and Education and Training. The venues can be seen in Figure 5.

Finally, the primary studies were classified based on keywords using open, axial, and pattern coding. Two of the primary studies became excluded in this phase because they did not have keywords. These classifications were used to identify the main thematic areas that empirical ISE studies occupy. Gender is notably missing from the classifications because all of these studies take a gender-forward, intersectional approach in their subject matter. The classifications were identified based on keywords mentioned by the author or identified by the publisher. Surprisingly, open source is mentioned the most, representing 18.6% of the primary studies. Keyword classifications can be seen in Figure 6.

4.2. Definition of Gender-Forward Intersectionality in Software Engineering

Gender-forward intersectionality is defined as the perspective of identifying and examining inequalities and discrimination with gender as the starting point. Gender is used as the starting point to explore how other traits may also impact software engineering experiences, both in design and use. Vorvoreanu et al. [151] investigate the gender biases in the Microsoft Academic search engine (https://www.microsoft.com/en-us/research/project/academic/ (accessed on 10 April 2024) using GenderMag and identify findings related to learning preferences, and cognitive diversity. Tuma et al. [126] presented a study to evaluate a form of risk analysis that begins with gender but also explores education, race, nationality, ethnicity, age, and seniority.

However, the application of gender-forward intersectionality goes beyond just the software engineering field. For example, Johnson et al. [152] discussed gender-forward intersectionality in the scope of a just energy transition, while Khalajzadeh et al. [153] applied gender-forward intersectionality as a lens to examine knowledge production and sustainability research. Research in global health and the COVID-19 pandemic has also applied gender-forward intersectionality [154]. As a result, gender-forward intersectionality has applicability beyond computing and should be applied beyond the software engineering context, where it is introduced.

4.3. Definition of ISE, Dynamics, and Relevant Research Topics

ISE, by definition, is a field of study in software engineering that acquires knowledge about power dynamics in software engineering in specific domains (e.g., education, industry, municipality, and non-governmental organizations) and environments (e.g., classroom, open source community, and workplace) using gender-forward intersectionality (e.g., female, non-binary, queer, trans, and male) or intersectionality as a framework.

ISE examines power dynamics. The dynamics are relevant to exploring power in four areas of software engineering, namely people, processes, products, and policies. This is done primarily using empirical software engineering research methods and gender-forward intersectionality or intersectionality guidelines highlighted by Turicos et al. [21]. The exploration of ISE dynamics is conducted in specific contexts and systems in more obtrusive ways in this field, and intersectionality is primarily examined from a gender-forward position, with findings and discussions being presented in a way that refers back to relevant stakeholders.

The people dynamic addresses demographic characteristics, but can also address internal characteristics like biases, perceptions, routines, emotional states, or other internal characteristics of people. Some examples of people-focused power dynamics ISE studies are Leventhal et al.’s [155] research, which questioned how computer scientists feel about ethics in the field; Sheedy’s research [132], in which the perceptions of all-male classes in computer science were gathered; Trinkenreich et al.’s paper [148], where the authors presented the experiences of women collected by survey and interview; and Wang et al.’s [156] exploration of the perceptions and attitudes about the workplace held by male software engineers.

The process dynamic addresses the processes in which a series of actions occur, serving to investigate team and production processes like agile, waterfall, recruitment, hiring, risk analysis, and the process of design. For instance, Leavy’s study [157] investigated the process of designing technologies. Santiesteban et al. [158] assessed the process of evaluating teaching which may affect the processes of tenure and promotion, while Tuma and Van Der Lee’s [126] examined the process of risk analysis.

The third dynamic is product, which investigates any phase of the life cycle of an artifact, application, or some other piece of software, be it based on the web, stored on devices, distributed, centralized, any other type of stored product, and regardless of it being free, licensed, or purchased. These investigations include the testing, design, prototyping, developing, and use or misuse of software. Some examples include Gralha et al.’s [159] and Santos et al.’s [160] explorations of GenderMag, as well as Krüger and Hermann’s [161] evaluation of online gender tools.

Finally, the policy dynamic refers to the examination of policies about gender in action. These can be recommendations or best practices, and can include workplace, local, or national initiatives like gender equity plans. The investigation of the United Nations Sustainable Development Goal 5 in relation to software engineering is also a policy study. Examples here include the study by Bastarrica et al. [162], which examines the impacts of a Gender Equality Admissions Program; Guizani et al.’s [163] investigation of a diversity and inclusion initiative in the Apache Software Foundation; and Motogna et al.’s [164] presentation of policies that help or hinder women’s success and progression. These are a few examples of each type of dynamic in research.

4.4. ISE Principles

From the dataset, we identified four principles of ISE, which are as follows:

• Principle 1: The data used in evaluations in ISE research must evaluate power imbalances.
• Principle 2: Dynamic power imbalances can be classified as: people, processes, products, or policies.
• Principle 3: Gender-forward intersectionality and intersectional study design leads the discussion of additional power imbalances, which may have confounding effects, found during the course of the study.
• Principle 4: Stakeholder findings about dynamics and power imbalances must relate to the impact on and identification of at least one stakeholder group.

In the next subsection, we verify the principles through the ABC framework using a set of 15 published empirical studies.

4.5. Selected Empirical Studies for ISE Validation

The dataset comprises 140 primary studies. Of those, 22.14% are from GE@ICSE, 13.57% are from the main ICSE conference, and 10.00% are from ICSE-SEIS. Of the dynamics, 47.14% investigate people, 25.71% examine process, 17.14% assess product, and 10.00% evaluate policy. GenderMag was either mentioned, adapted, evaluated, or used as the method of evaluation in 5.71% of the primary studies, making it the most mentioned tool. The representation of research strategies is shown in

Table 2. Composition of the research strategies in the 140 primary studies.

Quadrant	Research Strategy	Percentage of the Dataset
Quadrant 1	Field experiment	12.86%
Quadrant 1	Field study	21.43%
Quadrant 2	Experimental simulation	5.00%
Quadrant 2	Laboratory experiment	2.86%
Quadrant 3	Judgment study	5.71%
Quadrant 3	Sample study	32.86%
Quadrant 4	Formal theory	5.00%
Quadrant 4	Computer simulation	14.29%

, and the full list of articles reviewed can be found in the Appendix A.

Using purposive sampling, we identified 15 published empirical studies that are useful to highlight both ISE dynamics and a variety of research strategies. These studies show the scope of the ISE field and apply the definition and principles of ISE. These are presented in

Table 3. Example papers representing ISE definitions and principles.

Data#	Cit.	Actor	Behavior	Context	Dynamic	Quadrant, Strategy
D1	[165]	Students	Effects of gender bias	Classroom	People	1, Field experiment
D2	[163]	Contributors	Perceptions about D&I initiatives	Open source communities	Policy	1, Field study
D3	[166]	Software engineers	Biases	Industry	People	1, Field study
D4	[167]	Students	Decision making	Open source	Process	2, Laboratory experiment
D5	[159]	Users with little experience	Biometric behaviors	Universities and software companies	Product	2, Laboratory experiment
D6	[161]	Software	Identification of gender	Online gender identification systems	Product	2, Experimental simulation
D7	[168]	End-user programmers	Behavior patterns and thinking	Spreadsheets	Process	2, Experimental simulation
D8	[169]	Initiatives	Attitudes and biases	STEM organizations	Policy	3, Sample study
D9	[170]	Users	Sentiments, likes, and rankings	Google Play store	Product	3, Sample study
D10	[171]	Developers	Well-being and productivity	Remote working	People	3, Sample study
D11	[172]	DevOps teams	Awareness	Open source community	People	3, Judgment study
D12	[173]	Classification model	Performance	Real world datasets	Process	4, Computer simulation
D13	[174]	Initiatives	Successful strategies and partnerships	Brazil	Policy	4, Formal theory
D14	[175]	Projects	Biases and barriers	FOSS	Process	4, Formal theory
D15	[176]	Fairness	Gender bias	Sentiment analysis systems	Product	4, Computer simulation

.

We selected these studies because they highlight a range of studies that are conducted in the ISE field, depict the diversity of research strategies used in empirical software engineering, and demonstrate the relevance of these strategies to the exploration of gender-forward intersectionality in software engineering. In the following cases, we provide a brief summary of the article, as well as present the principles (P1–P4) of ISE, that is, we identify the evaluation, power dynamic, gender-forward intersectional traits, and relevant stakeholders. In addition, we identify the research strategy [13] of each study. The conditions each study meets are:

• Evaluation (P1);
• Dynamic (P2);
• Intersection (P3);
• Stakeholder (P4);
• Research quadrant and research strategy are presented.

Each principle will be presented in the cases that follow, which are organized and presented by their dynamics (i.e., people, process, product, and policy).

4.5.1. People

D1 investigated perceptions about and responses to gender in paired programming in a remote setting through a program that employs collaborative programming panes and chat windows. Perceptions about gender were explored in a variety of ways, and while no statistically significant results were found in the original study, statistical significance was found in the replication study.

• Evaluation: This study challenges the assumption that women are less technically competent than men by investigating perceived productivity based on the gender of the partner.
• Dynamic: Because this study expressly evaluated the perceptions about gender among students, it fulfills the qualifications for being about people.
• Intersection: Gender is explored as being both perceived and induced, and is also used to discuss geography, cultural background, language usage in chats, educational level, and technical competency.
• Stakeholder: Some relevant stakeholders include students, remote team managers, and industry partners with inter-generational and multi-gendered teams.
• This study is situated in Quadrant 1: Field experiment, and while it used the Twincode platform as a natural setting, the researchers manipulated the gender icon some users saw.

D3 examined the barriers software professionals experienced in the workplace in relation to their gender, as well as probed into micro-inequities (i.e., small negative reinforcing behaviors that may cause harm over time) for businesses to improve trainings and policies.

• Evaluation: This study explored the perceived barriers men and women encounter in their technical roles.
• Dynamic: This study is about people because it focused on workplace experiences.
• Intersection: Other traits that are discussed as a result of this exploration of gender are age, region, education, employment status, and years and role in software.
• Stakeholder: Some stakeholders were managers, human resources departments, researchers, and trainers.
• This study is situated in Quadrant 1: Field study, and while it explored professionals in their environment, it did not disturb the setting by data collection.

D10 examined the connections of well-being and productivity under the pandemic stress conditions caused by the COVID-19 pandemic, and the results were compared with the benefits afforded to voluntary work from home conditions.

• Evaluation: This study investigates the changes in well-being and productivity as a result of sharing space and splitting tasks and attention due to the COVID-19 pandemic.
• Dynamic: The researchers focused on software developers who had switched from working in an office to working from home during the COVID-19 pandemic.
• Intersection: Some additional traits that were explored include gender, employment status, age, co-habitation status, parental status, disability status, country of residence, role in organization, experience with working from home, and organization size.
• Stakeholder: Some stakeholders included companies, human resources offices, teams, and researchers.
• This study is situated in Quadrant 3: Sample study because of the nature in which the survey was disseminated and collected.

D11 presented findings related to study diversity in DevOps teams by gathering data from open source projects with a focus on identifying developer diversity by name.

• Evaluation: This study investigated the prevalence of ethnic and gender diversity in teams.
• Dynamic: Although the framing of this study requires awareness of diversity policies and uses pre-existing data, the focus is on the people dynamic because of the emphasis placed on the identification of gender and ethnic diversity in DevOps teams.
• Intersection: This study presented results regarding ethnic diversity, also called race, in addition to gender, and the researchers called for more investigation into diversity at intersections.
• Stakeholder: Some stakeholders included companies with diversity policies, managers, hiring committees, teams, and researchers.
• This study aligns with Quadrant 3: Judgment study because the data are actively designed to remove context but respond to stimulus.

4.5.2. Process

D4 investigated the role gender plays in the decision to accept or reject a pull request.

• Evaluation: Gender bias was the power dynamic evaluated.
• Dynamic: This study examined the time participants spent looking at code snippets and other details before making a decision, so it is considered to explore the process dynamic (i.e., a study about information processing and decision making).
• Intersection: Other characteristics of note were age, country of origin, and whether participants were a minority in their country of origin.
• Stakeholder: Relevant stakeholders included students, researchers, and teams.
• Because this study took place in a controlled environment, it is an example of Quadrant 2: Laboratory experiment.

D12 explored the impact that decision-making machine-learning software can have on amplifying biases through the creation of a search-based method. The authors expressed the effects that such software may have on mitigating bias, repairing fairness issues, and retaining classification accuracy.

• Evaluation: The power dynamics investigated are systemic and unintentional discrimination, along with their impacts on fairness and accuracy for decision-making software.
• Dynamic: Because this study presented a novel method to be employed, this study investigates the process dynamic.
• Intersection: Other traits discussed in this paper were race and age.
• Stakeholder: This work is relevant to software engineers, researchers, and others who use or design systems that use logistic regression and decision trees for binary decision making.
• This study is situated in Quadrant 4: Computer simulation because all data and research processes took place in a non-empirical setting with no recorded observations.

D7 explored the impacts of gender differences on debugging strategies in end-user programmers.

• Evaluation: This study investigated how end user programmers use tools and strategies to debug spreadsheets.
• Dynamic: It assessed the process of debugging through a specific form, called “What You See Is What You Test,” to understand behaviors and the thought process behind problem-solving strategies.
• Intersection: Other traits at the intersection were gender, experience, major, and self-efficacy.
• Stakeholder: Some stakeholders include support staff, end-user programmers, project managers, and researchers.
• This study is situated in Quadrant 2: Experimental simulation because researchers replicated conditions that the participants would be familiar with and may experience in the real world.

D14 replicated two studies that explored gender biases in free and open-source (FOSS) communities based on code reviews and acceptance.

• Evaluation: This study investigated whether the acceptance of code reviews is impacted by the gender of the developer.
• Dynamic: It examined the process of submitting and accepting code reviews across projects and platforms.
• Intersection: Other relevant points that were discussed through exploring gender included the “prove it again” process, where members of marginalized and non-dominant groups were forced to explain their work, and the impact of other biases on the code review process. The study also employed a gender-neutral categorization.
• Stakeholder: This study explicitly mentions project managers, researchers, and prospective new members in free and open-source communities as relevant stakeholders.
• This study aligns with Quadrant 4: Formal theory because it sought to develop a conceptualization or framework as a replication study.

4.5.3. Product

D5 identified how the facets of GenderMag can be applied to participants while creating, interpreting, and using iStar goal models.

• Evaluation: This study evaluated speed, accuracy, and attitudes towards risk to assess information processing and how gender diversity can impact problem-solving in software teams.
• Dynamic: Because this study expressly applied GenderMag facets, it investigated the product dynamic.
• Intersection: Other traits that were explored included nationality, education, occupation, age, and use of a screen reader.
• Stakeholder: Some relevant stakeholders were software developers, researchers, teams, educators, and hiring managers.
• This quasi-experiment is a representation of Quadrant 2: Laboratory experiment because of the contrived setting and the high degree of control the researchers had over variables and participants.

D6 questioned whether it is possible to correctly detect someone’s gender based on name, images, or other textual information.

• Evaluation: This study challenged other studies that tried to infer or detect gender based on name and other qualities that may be visible to platform users.
• Dynamic: This study investigated whether an online service, or product, can correctly identify gender from text.
• Intersection: The study presents the possible harmful effects of assuming and maintaining the gender binary in research. Other marginalized groups are also mentioned as a point of inclusion.
• Stakeholder: Some stakeholders are researchers, developers, and others who should be mindful about how choices to omit people from research may exacerbate negative repercussions.
• This study aligns with Quadrant 2: Experimental simulation because it investigated a concrete class of settings as closely as possible.

D9 explored the potential impact that user feedback on the Google Play store may have on app updates and debugging. Developer feedback was also included in the exploration.

• Evaluation: Because of the nature of the feedback provided by users that present as male or female, decisions about features and updates may favor male users’ opinions and disenfranchise female users.
• Dynamic: This study investigated the product dynamic through its exploration of user feedback along with its incorporation into design.
• Intersection: Other traits that were discussed were devices, connectivity, and speed, which are connected to socioeconomic status, geographical region, and other bias-related traits. In addition, language usage is suggested as a future study based on initial utterance findings.
• Stakeholder: This study is relevant to users, app developers, and designers.
• This work is situated in Quadrant 3: Sample study because it was set in a neutral setting, no variables were manipulated, and the researchers had to deal with the data collected based on their parameters.

D15 investigated sentiment analysis systems using distributional and relational fairness.

• Evaluation: This study explored a tool created to fill the gap of monitoring and uncovering biased predictions at runtime.
• Dynamic: This study investigated the product dynamic because it presented a tool created to detect gender bias in sentiment prediction.
• Intersection: Some other variables were gender, race, and sexual orientation.
• Stakeholder: This study is relevant to app developers and designers.
• This study is situated in Quadrant 4: Computer simulation because of its use of IMDB data.

4.5.4. Policy

D8 articulated the role that gender quotas and related initiatives have played in computing fields in the United Kingdom.

• Evaluation: This study investigated different barriers experienced by women trying to achieve gender parity at an organizational level, and called for a focus on support networks and role modeling.
• Dynamic: This exploration of policy initiatives in practice was used to identify best practices for advancing gender parity.
• Intersection: The study called for a recognition of global diversity and inclusion.
• Stakeholder: Relevant stakeholders are researchers, educators, managers, and practitioners in computing disciplines who also want to advance gender parity.
• This study is an example of Quadrant 3: Sample study because of its limited precision, lack of variable manipulation, and aim of evaluating the distribution of the target population.

D2 assessed people’s perceptions and understanding of diversity and inclusion initiatives in the Apache Software Foundation (ASF).

• Evaluation: This study assessed diversity and inclusion.
• Dynamic: Because this paper investigated perceptions of and understandings about diversity and inclusion policies to assess implementation and improvement, this was an investigation about the policy dynamic.
• Intersection: Other intersectional traits identified by the authors were age, seniority, education, compensation, location, and language proficiency.
• Stakeholder: Some relevant stakeholders here were members of open source communities, OSS community managers, and OSS organizations.
• This study takes place in the Apache Software Foundation’s Diversity and Inclusion Committee via on-site surveys and interviews, so it represents Quadrant 1: Field study.

D13 presented a national program and sister projects developed under the national directorship of Brazil’s SBC Regional Secretariat.

• Evaluation: This study outlined initiatives and programs that aimed to increase the number of women in computer science fields.
• Dynamic: Because this paper presented regional initiatives started because of the SBC Regional Secretariat and planned for further national strategies, this represented the policy dynamic.
• Intersection: Other characteristics that were highlighted were socioeconomic factors, geographic location, and education.
• Stakeholder: Relevant stakeholders mentioned by the authors were other programs, researchers, and educators, as well as private businesses that want to support these efforts.
• This study aligns with Quadrant 4: Formal theory because the work is conducted in a nonempirical setting, and the study focuses on relationships between concepts, namely in the connection of networks.

In addition to these 15 example cases, there are other ways to show ISE in action.

4.6. ISE Reach

Just like Stol and Fitzgerald used the ABC framework in the context of requirements engineering and the global software engineering field and showcased that they can be applied in the context of empirical software engineering, we used this framework to show that ISE studies can be situated in empirical software engineering. Therefore, anything that is used for students and practitioners to learn about ISE should be considered within the scope of the field, while power dynamics are an exclusive aspect of ISE and should be evaluated using the ABC Framework.

Research questions in ISE consider imbalances of power related to software engineering domains, employ either gender-forward intersectionality or the framework and guidelines for intersectionality, and investigate the impacts of power imbalances on stakeholders. Creating good research questions may seem complex. Some examples of well-designed research questions include:

• “RQ1. What is the landscape of intersectional identities in software development and use? RQ2. Where are intersectional populations contributing data? RQ3. How do marginalized populations feel about the impact technology has on their day to day lives?” [123]
• “RQ1. How does the number of community smells differ in teams without women and in teams with women? To what extent does the presence of women within teams influence the number of community smells?” [96]
• “How Does Instructor Type and Gender Affect Student Perceptions and Learning Outcomes?” [177]

Intersectional software engineering studies must also conduct research well. This means following the guidelines presented in Turcios et al. [21] to intentionally design research. Employing these guidelines and teaching them in software engineering classes, along with gender-forward intersectionality as a guiding principle will ensure critical thinking and construct more relevant and impactful products and use cases.

4.7. ISE Tools and Datasets

The ISE field has a growing collection of tools, datasets, best practices, and recommendations to address systemic problems related to gender in academia, industry, and society. Some relevant tools to help explore gender as mentioned in the primary studies are as follows:

• AID: Automated Inclusivity-Bug Detector (See: https://zenodo.org/records/4007579 (accessed on 22 April 2024)
• BiasRV (See: https://www.youtube.com/watch?v=WPe4Ml77d3U (accessed on 22 April 2024), See: https://github.com/soarsmu/BiasRV (accessed on 22 April 2024)
• CODEFACE4SMELLS tool (See: https://github.com/maelstromdat/CodeFace4Smells (accessed on 22 April 2024)
• Digital.ai (See: https://digital.ai/ (accessed on 22 April 2024)
• Gender-API (See: https://gender-api.com/ (accessed on 22 April 2024)
• Gender Guesser (See: https://gender-guesser.com/ (accessed on 22 April 2024)
• Genderize (See: https://genderize.io/ (accessed on 22 April 2024)
• GenderComputer (See: https://github.com/tue-mdse/genderComputer (accessed on 22 April 2024) for download and use;
• GenderizeR (See: kalimu/genderizeR: R package for gender predictions (accessed on 22 April 2024), the R plugin for Genderize;
• GenderMag (See: https://gendermag.org/index.php (accessed on 22 April 2024));
• Genni: The gender predictor (See: http://abel.lis.illinois.edu/cgi-bin/genni/search.cgi (accessed on 22 April 2024)
• HaTe Detector (See: https://github.com/INSPIRED-GMU/HaTe-Detector (accessed on 22 April 2024)
• Inclusive Design Toolkit (See: https://www.inclusivedesigntoolkit.com/simsoftware/simsoftware.html (accessed on 22 April 2024)
• InclusiveMag and the MagFamily (See: https://ieeexplore.ieee.org/document/8818889 (accessed on 22 April 2024);
• iStar (See: https://microlina.github.io/Framework/tools/iStarLab2.0/ (accessed on 22 April 2024)
• Name Prism (See: https://www.name-prism.com/ (accessed on 22 April 2024)
• RusProfilingLab and the Gender Imitation Corpus (See: https://rusidiolect.rusprofilinglab.ru/login/?next=/rusprofiling-at-pan/corpus/ (accessed on 14 August 2024)
• SESMag (See: https://gendermag.org/sesmag/ (accessed on 22 April 2024)
• Teaching Materials for GenderMag, InclusiveMag, and SESMag (See: https://oercommons.org/groups/gendermag-teach-inclusivemag/10149/17796/5348/ (accessed on 14 August 2024)

GenderMag [143] is often-mentioned and well-researched. GenderMag is both a method and a persona generation tool that is used to assist in identifying bias through the use of personas and their facets. The team is working to produce an intersectionality magnifier tool, but it is not ready at the time of publication.

ISE has also produced usable datasets for reproducible studies and to design new projects and research questions. The list of datasets identified in the primary sources is:

• Conference Leadership Dataset (See: https://docs.google.com/spreadsheets/d/119JiFYxrYAik75MlLTPqqmO6K6mdbn3qIzKLxx5xMd0/edit?usp=sharing accessed on 13 January 2025);
• Draw a Software Engineer Dataset (See: https://www.ntnu.no/wiki/display/DASET/DASET+-+Perceptions+of+Software+Engineering+Profession accessed on 13 January 2025);
• Fairness Post-processing (See: https://github.com/SOLAR-group/Fairness-Postprocessing accessed on 13 January 2025);
• Replication package for “Code reviews in Open Source Projects” (See: https://zenodo.org/records/7608539 accessed on 13 January 2025);
• Replication package for “Gender Diversity and Women in Software Teams: How Do They Affect Community Smells?” (See: https://figshare.com/s/a144c4bcf3839952477b accessed on 13 January 2025);
• Social Goal Models (See: https://zenodo.org/records/3819208 accessed on 13 January 2025)

4.8. Teaching ISE

For university software engineering classrooms, the goal should be to develop a dedicated unit, module, or course to teach ISE in the same ways students are exposed to other disciplines and fields of study. In a course about ISE research methods, a presentation of the seminal papers or example cases can be presented and discussed. Picking a keyword classification and constructing a discussion or based on quadrants can facilitate engagement with the material. For example, an assignment based on team dynamics can include Hilderbrand et al. [92] representing Quadrant 1, Durán Toro et al. [53] representing Quadrant 2, Vasilescu et al. [149] representing quadrant 3, and Catolino et al. [36] representing Quadrant 4. Additionally, many papers can be used to design a module to explore GenderMag by Burnett et al. [31] about the development of a method of evaluating gender bias in products.

Simulations exploring gender and intersectionality are emerging discussions of study in the field of software engineering. These studies reflect some examples of research classified as ISE, showcasing the employment of various methods by software engineering researchers using empirical research methods, highlighting relevant classroom applications. ISE uses existing frameworks and methods for data analysis and data collection, and these methodologies can also be examined and refined in ISE as a part of process power dynamics. Examples of common methodologies used in ISE can be seen in

Table 4. Methodological frameworks, data collection, and data analysis used in ISE studies.

ISE Framework	Methodological Framework	Collection/Generation	Analysis
Gender-forward intersectionality	Action research	A/B test	Conceptual analysis
Intersectionality	Actor-network theory	Alpha or beta test	Concept mapping
	Case study	Biometric evaluation	Content analysis
	Correlation study	Diary study	Correlational study
	Data feminism	Field observation	Discourse analysis
	Delphi study	Focus group/group interview	Knowledge graph
	Design cycle	Heuristic evaluation	Network analysis
	Design and creation	Interview	Probabilistic modeling
	Ethnography	Latent Dirichlet allocation	Social network analysis
	Feminist HCI	Participant observation	Statistical analysis
	GenderMag	Pre-/post-test	Thematic analysis
	Goal/question/metric paradigm	Survey
	Grounded theory	System test
	Material semiotic method	Usability test
	Participatory design	User-focused task
	Systematic literature review
	Systematic mapping study
	What you see is what you test

. It should be noted that these columns offer choice in the design of a study. Each line does not correspond with the other items across columns.

Thematic analysis includes numerous coding schemas, as defined by Saldana [178]. Statistical analysis encompasses many types of relational analyses including analysis of variance, t-test, chi-square, and regression analyses (e.g., correlation analysis, multiple regression analysis, and principal component analysis). Card sorting, design thinking, gamification, and maker spaces are also employed in ISE, having been commonly used in conjunction with methods from other disciplines. Importantly, the frameworks and methods described in this subsection are not intended to cover all methods used in the field, but rather to serve as a preliminary outlining of the main methods and tools used to examine dynamics in ISE, particularly highlighting what is identified in the literature.

5. Discussion

The main contributions for the paper are as follows:

• Highlight 1: ISE is introduced as a field of study with over 20 years of empirical research.
• Highlight 2: Gender-forward intersectionality is defined.
• Highlight 3: The power dynamics of ISE are presented as extrapolated from the literature.
• Highlight 3: Principles, tools, methods, and applications of the results are presented.

As presented in the Introduction section, ISE builds on and expands a tradition of embedding values into computing. This incorporation benefits from the inclusion of women and marginalized groups in the computing field by raising awareness of and mitigating biases in design. Intersectional software engineering addresses issues such as gender biases in software design, development, and team dynamics and highlights other challenges to power based on marginalized traits. It is important to consider these distinctions if we are to establish ISE as a specialized field within software engineering. In providing a clear definition of the boundaries and unique contributions of ISE, this paper highlights its relevance and key role in addressing gender biases and promoting inclusivity within the software engineering discipline. This differentiation also helps to avoid confusing ISE with broader feminist computing topics and ensure that the specific challenges and solutions within software engineering are adequately addressed.

Gender-based research has been discussed in empirical studies in software engineering since the 1990s (e.g., [155]), and the importance of diversity has been a growing topic in the last few years in the field. However, as previously presented in this paper, the authors feel that a common and more standardized approach to guide the rules and correct steps for conducting and observing intersectional traits in software engineering is needed. This definition of the empirical framework has the potential to not only improve the quality of gender-related and intersectional studies but also give researchers and participants interested in the topic a common language for discussing, evaluating, and comparing the empirical results. If considered as a field of study, ISE stands to offer a comprehensive examination of the interplay between people, processes, products, and policies within software development. This renders the formalization of ISE as a field a potential pathway for invested stakeholders to codify the analysis of power dynamics across various dimensions and facilitate the exploration of gender inclusivity, diversity, and bias in software engineering.

By conducting a systematic mapping study, we defined the field, defined a core definition, and used a set of example papers to show gender-forward intersectional studies in particular are ISE studies. By also presenting the commonly used methods, examples of well-designed research questions, and the datasets and tools that are constructed for ISE research, we highlight that the field has been productive for decades.

Accordingly, we hold that ISE is an active field of research and should thus be recognized as a discipline warranting further academic concentration or specialization, and as a discipline that students can major in. This field should be formally recognized owing to the growing popularity and interest in workshops like GE@ICSE (See: https://conf.researchr.org/series/ge-icse accessed on 3 July 2024) and intersectionality and software engineering at Foundations of Software Engineering (See: https://intersectionalitywork.github.io/ accessed on 10 October 2024), conferences like Women and Code (See: https://womenandcode.org/ accessed on 3 July 2024) and ACM womENcourage (See: https://womencourage.acm.org/ accessed on 3 July 2024),professional organizations like ACM-Women (See: https://women.acm.org/ accessed on 3 July 2024) and IEEE Women in Engineering (See: https://wie.ieee.org/ accessed on 3 July 2024)), and international initiatives like EUGAIN (See: https://eugain.eu/ accessed on 3 July 2024)). Commonalities across all of these spaces is the emphasis on reducing workplace toxicity, producing better products in a more efficient way, and other issues that affect women and gender minorities in the computing field. The contributions that ISE makes to society include the promotion of policies, recommendations, and initiatives that improve work cultures and work–life balance for many, as shown in the subset of papers used to highlight the principles of ISE in practice.

5.1. Challenges

Advocating the recognition of ISE as a specialized field of study is a noble initiative that will definitely pique the interest of several researchers. Still, in the software engineering field, some researchers may not be interested in completing studies in intersectional software engineering or may fight the idea of having ISE as a field of study because they will prefer to maintain the status quo. Efforts to fight against the formalization of the ISE field may include the pushback of research ideas. These highlight challenges that researchers specializing in the ISE field may face in terms of collaborations, visibility, citations, and the recruitment of non-female researchers. While these challenges may seem to arise in reaction to ISE as a field of study, some of them have existed for decades and are persistent today. Thus, legitimizing the field may provide a structured and coherent historical context to combat narratives about women, girls, and marginalized groups and their participation in software engineering as both an educational area and a career.

5.2. Threats to Validity

Conducting a systematic mapping study entails the need to consider several potential threats to validity in order to ensure finding robustness and reliability, this section discusses threats to validity in our own work and those that may arise when applying the proposed ISE definitions and principles. These threats can be categorized into construct validity, internal validity, external validity, and conclusion validity.

5.2.1. Construct Validity

Construct validity serves to describe the degree to which the study accurately measures the concepts it intends to measure, and common threats to such validity in this systematic mapping study may include:

• Non-specification of the mapping study’s setting and sufficient details [139];
• Incorrect or incomplete search terms in automatic search [179].

5.2.2. Internal Validity

Internal validity concerns the extent to which the results of the study can be attributed to the interventions or variables being tested, rather than other factors, and some common threats to internal validity in systematic mapping studies may include:

• Bias in study selection [139];
• Identification error of primary studies in the searching process [179];
• Paper/database inaccessibility [179];
• Misclassification of primary studies [139];
• Subjective interpretation about the extracted data [139];
• Subjective quality assessment [139].

5.2.3. External Validity

External validity concerns the generalizability of the study findings to other settings, populations, or times, and common threats to external validity that may occur in systematic mapping studies include the following:

• Culture bias: Cultural differences among researchers can lead to biased interpretations and conclusions [139];
• Incomplete research information in primary studies: The lack of detailed information in primary studies can affect finding generalizability [179];
• Primary study generalizability: The generalizability of the primary studies to the broader research area can affect the overall validity of the mapping study [139].

5.2.4. Addressing the Threats to Validity

To address these threats to validity, we have:

• Developed protocols in accordance with the guidelines for systematic mapping studies in software engineering [139] for the study during the planning phase.
• Developed a rigorous search strategy that combines automatic and manual search methods, used multiple databases (i.e., Scopus, ACM Digital Library, and IEEE), and targeted specific venues.
• Developed standardized terminologies through internal discussion among the authors to ensure consistency in language and terminology.
• Defined the inclusion and exclusion criteria for studies.
• Applied a multi-step selection process and built standard review protocols.
• Applied bias mitigation methods by carefully reading through papers. For example, we documented reasons for the exclusion of studies, ensured that multiple authors performed data extraction and keyword classification, and discussed until reaching consensus on matters pertaining to keyword classification, power dynamics, research strategy, and the application of the principles of ISE.
• Conducted a pilot study for data synthesis and used internal evaluations to ensure quality.
• Selected papers from researchers outside our immediate networks for the ten seminal papers and the 15 example cases.

6. Conclusions

This study introduces ISE as a distinct field within software engineering, underlining its significant contributions to advancing software engineering research on power dynamics by investigating people, processes, products, and policies through the lens of gender-forward intersectionality. We make the case that ISE warrants the status of a specialized research field by demonstrating how related scholarship aligns with the ABC framework, and how ISE offers novel perspectives on diversity and inclusion in work, education, and in software engineering product and process development. The study also unveils the unwavering dedication of the growing community of researchers, practitioners, and educators specializing in ISE to improving software engineering methods and processes through inclusion and diversity promotion across various dimensions. The goal of this emerging field is to create a more inclusive and equitable future in software engineering by adopting a holistic approach that integrates both empirical research and solutions that value intersectional traits.

While the paper emphasizes gender-forward intersectionality, it offers a starting point to address other Intersectional factors such as race, disability, or socioeconomic status. Enhancing the ISE framework will require the adoption of a more holistic approach to intersectionality such that it addresses multiple axes of marginalization. Including case studies or examples that highlight the interplay of gender with other traits, such as ethnicity or physical ability, would provide a more comprehensive understanding as well.