Research in social accessibility aims to improve the lives of disabled people across diverse abilities and experiences by assisting with communication, relationships, and ecosystems of access. We seek to understand this intersectional body of work through analyzing social accessibility research from 2011 to 2025. Through constructivist grounded theory analysis of 90 papers (curated from 605), we develop the Three Praxes Framework: three sites of practice Artifact (constructive), Ecosystem (relational), and Epistemology (theoretical) - two cross-cutting stances toward change (Temporal Orientation and Stakeholder Focus) - and one reflexive cycle modeling how insights can flow between praxes. Our analysis reveals these praxes operate largely in isolation, risking that insights remain academic exercises while assistive technologies reinforce existing barriers. We call on the field to realize a cycle where disabled people's lived experiences shape material realities, material practice generates theoretical knowledge, and both transform ecosystems of access.

Social accessibility research faces a persistent tension: assistive technologies (AT) predominantly pursue independence, yet disabled people’s experiences reveal rich preferences for interdependence. Our analysis of 90 papers from 2011-2025 uncovered that this stems from a deeper issue—which crystallized through dialogue with three bodies of theories: (1) self-determination theory (SDT), (2) symbolic interactionism, and (3) posthumanist perspectives and crip technoscience. SDT illuminates individual needs; symbolic interactionism addresses construction of social meaning and stigma; Posthumanist and crip technoscience together challenges normalcy, governance, and the human-machine boundary. Through their tensions, we identify relational sovereignty as an alternative telos—or goal—to autonomy. While our corpus equates autonomy with independence, sovereignty centers the power to choose between independence and interdependence. To operationalize this shift—from “Can they do it?” to “Do they get to decide?”— we introduce the Relational Sovereignty Matrix and four design interventions: (1) a sovereignty-centered reframing of SDT, (2) generative questions for justice-oriented reflection, (3) the idea of building through sovereign technical primitives, and (4) explicit consideration of power in AT design.

Deciding whether to disclose neurodivergence at work is hard; disclosing can lead to positive outcomes, but also to stigma or job insecurity.These outcomes are hard to predict and not well understood.Accordingly, neurodivergent workers turn to online communities, which may not inform well-calibrated disclosure decisions.We conducted a mixed-methods study on disclosure of neurodivergence in software workplaces.We focus on software workplaces because neurodivergence is prevalent there, and they present unique interactions for disclosure.We compare community perceptions on r/ADHD_Programmers with a worldwide survey of 493 software engineers.Synthesizing these perspectives, we constructed a model of disclosure in our context, uncovering the cost-benefit analyses of disclosure, disclosure outcomes, and the influence of mental health.We found that workplace disclosure is often motivated by social support and outcomes are predominantly positive.We conclude with a call for future interventions, including technologies, to optimize disclosure decisions.

Understanding the work styles of diverse programmers can help build inclusive workplaces, enabling all software engineers to excel. An estimated 10.6 % of programmers have Attention Deficit Hyperactivity Disorder (ADHD), a condition characterized by differences in attention and working memory. Prior work has just begun to explore the impact of ADHD on software development, finding that inadequate support may negatively impact team productivity and employment. This prevents software organizations from benefiting from ADHD-related strengths. To investigate these impacts, we conducted a two-phase mixed methods study. First, we qualitatively analyzed 99 threads (1,658 posts and comments) from r/ADHD_Programmers, the largest public forum dedicated to the ADHD programmer community. We constructed a mapping that reveals how ADHD programmers apply personal strategies and organizational accommodations to address software task-specific challenges. Second, we conducted a large-scale survey of 239 ADHD and 254 non-ADHD professional programmers to validate how our qualitative data generalize to the worldwide developer population. Our results show that ADHD programmers are 1.8 to 4.4 times more likely to struggle more frequently than neurotypical developers with all challenges we consider, but especially with time management and design. Our findings have implications for inclusive and effective tooland policy-building in software workplaces and motivate further research into the experiences of ADHD programmers.

Autistic adults often experience stigma and discrimination at work, leading them to seek social communication support from coworkers, friends, and family despite emotional risks. Large language models (LLMs) are increasingly considered an alternative. In this work, we investigate the phenomenon of LLM use by autistic adults at work and explore opportunities and risks of LLMs as a source of social communication advice. We asked 11 autistic participants to present questions about their own workplace-related social difficulties to (1) a GPT-4-based chatbot and (2) a disguised human confederate. Our evaluation shows that participants strongly preferred LLM over confederate interactions. However, a coach specializing in supporting autistic job-seekers raised concerns that the LLM was dispensing questionable advice. We highlight how this divergence in participant and practitioner attitudes reflects existing schisms in HCI on the relative privileging of end-user wants versus normative good and propose design considerations for LLMs to center autistic experiences.

Code readability is crucial for program comprehension, maintenance, and collaboration. However, many of the standards for writing readable code are derived from sighted developers’ readability needs. We conducted a qualitative study with 16 blind and visually impaired (BVI) developers to better understand their readability preferences for common code formatting rules such as identifier naming conventions, line length, and the use of indentation. Our findings reveal how BVI developers’ preferences contrast with those of sighted developers and how we can expand the existing rules to improve code readability on screen readers. Based on the findings, we contribute an inclusive understanding of code readability and derive implications for programming languages, development environments, and style guides. Our work helps broaden the meaning of readable code in software engineering and accessibility research.

The marginalization of autistic people in our society today is multi-faceted as it includes violence that is both physical and ideological in nature. It is rooted in the dehumanization, infantilization, and masculinization of autistic people and pervasive even in contemporary research studies that continue to echo ableist ideologies from the past. In this work, we identify how HRI research reproduces systemic social inequalities and explain how they align with historical misrepresentations, and other systemic barriers. We analyzed 142 papers focusing on HRI and autism published between 2016 and 2022. We critique these studies through a mixed-methods analysis of their definition of autism, study designs, participant recruitment, and results. Our findings indicate that HRI research stigmatizes autism in three dimensions - 1) the pathologization of autism, 2) gender and age-based essentialism, and 3) power imbalances. Our work uncovered that about 90% of HRI research during the timeline explored excluded the perspectives of autistic people, particularly those from understudied groups. We recommend broadening the inclusion of autistic people, considering research objectives beyond clinical use, and diversifying collaborations, foundational works considered, & participant demographics for more inclusive future work.

The access needs of neurodivergent individuals in organizational settings are many and varied - and so are their everyday contributions to the creation of collective access. In this study, we contribute to the growing body of CSCW research on accessibility and investigate the invisible access labor of neurodivergent students in three computer science institutions. We use an exploratory, multi-stakeholder approach, combining semi-structured interviews (n=26) and document analysis. We adopted a broad definition of neurodiversity: our study included individuals with autism, dyslexia, ADHD, cyclothymia and individuals with neurological conditions that developed as a result of illness, trauma or injury. Our findings show that neurodivergent students face a number of structural and attitudinal barriers to access in the educational environment and within the disability support system. We identified barriers in three main areas: (i) assistive technology access barriers, (ii) cognitive and physical access barriers, and (iii) social access barriers. We examined how stigma, individualized understandings of disability and intersectional disadvantage shape organizational practices and explored how students are creatively improving collective access through micro-interventions, although these efforts are largely invisible. We then draw on our findings to identify opportunities for change. We propose access grafting as a bottom-up approach to rethinking and reorienting organizational strategies to improve equitable access.

COVID-19 accelerated the trend toward remote software development, increasing the need for tightly-coupled synchronous collaboration. Existing tools and practices impose high coordination overhead on blind or visually impaired (BVI) developers, impeding their abilities to collaborate effectively, compromising their agency, and limiting their contribution. To make remote collaboration more accessible, we created CodeWalk, a set of features added to Microsoft’s Live Share VS Code extension, for synchronous code review and refactoring. We chose design criteria to ease the coordination burden felt by BVI developers by conveying sighted colleagues’ navigation and edit actions via sound effects and speech. We evaluated our design in a within-subjects experiment with 10 BVI developers. Our results show that CodeWalk streamlines the dialogue required to refer to shared workspace locations, enabling participants to spend more time contributing to coding tasks. This design offers a path towards enabling BVI and sighted developers to collaborate on more equal terms.

Although the number of blind or low vision (BLV) software developers is the largest minority population of developers with physical disabilities, they are often marginalized in mainstream online programming communities. We studied how BLV developers engage with a BLV-specific programming community called Program-L, by exploring the help-seeking behaviors of novices. We analyzed 173 messages written by 20 novices over a 4-year period and identified the kinds of help they asked for and their justifications for requesting that help. We learned that self disclosure, practical assistance, and community dynamics were all critical activities to support four types of novices: community, domain, programming, and accessibility. The findings of our work give insight into what support can look like for online communities for marginalized software developers.

The COVID-19 pandemic forced many people to convert their daily work lives to a “virtual” format where everyone connected remotely from their home. In this new, virtual environment, accessibility barriers changed, in some respects for the better (e.g., more flexibility) and in other aspects, for the worse (e.g., problems including American Sign Language interpreters over video calls). Microsoft Research held its first cohort of all virtual interns in 2020. We the authors, full time and intern members and affiliates of the Ability Team, a research team focused on accessibility, reflect on our virtual work experiences as a team consisting of members with a variety of abilities, positions, and seniority during the summer intern season. Through our autoethnographic method, we provide a nuanced view into the experiences of a mixed-ability, virtual team, and how the virtual setting affected the team’s accessibility. We then reflect on these experiences, noting the successful strategies we used to promote access and the areas in which we could have further improved access. Finally, we present guidelines for future virtual mixed-ability teams looking to improve access.

Communication and teamwork are essential skills for software developers. However, these skills are often difficult to learn for students with autism spectrum disorder (ASD). We designed, developed, and ran a 13-day, remote video game coding camp for incoming college first-year students with ASD. We developed instructional materials to teach computer programming, video game design, and communication and teaming skills. Students used the MakeCode Arcade development environment to build their games and Zoom to remotely collaborate with their teammates. In summative interviews, students reported improved programming skills, increased confidence in communication, and better experiences working with others. We also found that students valued the opportunity to practice teaming, such as being more vocal in expressing ideas to their peers and working out differences of opinion with their teammates. Two students reported the remote learning environment decreased their anxiety and stress, both are frequent challenges for autistic people. We plan to rerun the camp next year with materials that we have made available online.

Through an iterative design process using Wizard of Oz (WOz) prototypes, we designed a video calling application for people with Autism Spectrum Disorder. Our Video Calling for Autism prototype provided an Expressiveness Mirror that gave feedback to autistic people on how their facial expressions might be interpreted by their neurotypical conversation partners. This feedback was in the form of emojis representing six emotions and a bar indicating the amount of overall expressiveness demonstrated by the user. However, when we built a working prototype and conducted a user study with autistic participants, their negative feedback caused us to reconsider how our design process led to a prototype that they did not find useful. We reflect on the design challenges around developing AI technology for an autistic user population, how Wizard of Oz prototypes can be overly optimistic in representing AI-driven prototypes, how autistic research participants can respond differently to user experience prototypes of varying fidelity, and how designing for people with diverse abilities needs to include that population in the development process.

Video calling (VC) aims to create multi-modal, collaborative environments that are "just like being there." However, we found that autistic individuals, who exhibit atypical social and cognitive processing, may not share this goal. We interviewed autistic adults about their perceptions of VC compared to other computer- mediated communications (CMC) and face-to-face interactions. We developed a neurodiversity-sensitive model of CMC that describes how stressors such as sensory sensitivities, cognitive load, and anxiety, contribute to their preferences for CMC channels. We learned that they apply significant effort to construct coping strategies to support their sensory, cognitive, and social needs. These strategies include moderating their sensory inputs, creating mental models of conversation partners, and attempting to mask their autism by adopting neurotypical behaviors. Without effective strategies, interviewees experience more stress, have less capacity to interpret verbal and non-verbal cues, and feel less empowered to participate. Our findings reveal critical needs for autistic users. We suggest design opportunities to support their ability to comfortably use VC, and in doing so, point the way towards making VC more comfortable for all.

Having great managers is as critical to success as having a good team or organization. In general, a great manager is seen as fuelling the team they manage, enabling it to use its full potential. Though software engineering research studies factors that may affect the performance and productivity of software engineers and teams (like tools and skills), it has overlooked the software engineering manager. The software industry's growth and change in the last decades is creating a need for a domain-specific view of management. On the one hand, experts are questioning how the abundant work in management applies to software engineering. On the other hand, practitioners are looking to researchers for evidence-based guidance on how to manage software teams. We conducted a mixed methods empirical study of software engineering management at Microsoft to investigate what manager attributes developers and engineering managers perceive important and why. We present a conceptual framework of manager attributes, and find that technical skills are not the sign of greatness for an engineering manager. Through statistical analysis we identify how engineers and managers relate in their views, and how software engineering differs from other knowledge work groups in its perceptions about what makes great managers. We present strategies for putting the attributes to use, discuss implications for research and practice, and offer avenues for further work.

Having great managers is as critical to success as having a good team or organization. A great manager is seen as fuelling the team they manage, enabling it to use its full potential. Though software engineering research studies factors that may affect the performance and productivity of software engineers and teams (like tools and skill), it has overlooked the software engineering manager. On the one hand, experts are questioning how the abundant work in management applies to software engineering. On the other hand, practitioners are looking to researchers for evidence-based guidance on how to manage software teams. We conducted a mixed methods empirical study to investigate what manager attributes developers and engineering managers perceive important and why. We present a conceptual framework of manager attributes, and find that technical skills are not the sign of greatness for an engineering manager. Through statistical analysis we identify how engineers and managers relate in their views, and how software engineering differs from other knowledge work groups.

The demand for analyzing large scale telemetry, machine, and quality data is rapidly increasing in software industry. Data scientists are becoming popular within software teams. For example, Face-book, LinkedIn and Microsoft are creating a new career path for data scientists. In this paper, we present a large-scale survey with 793 professional data scientists at Microsoft to understand their educational background, problem topics that they work on, tool usages, and activities. We cluster these data scientists based on the time spent for various activities and identify 9 distinct clusters of data scientists and their corresponding characteristics. We also discuss the challenges that they face and the best practices they share with other data scientists. Our study finds several trends about data scientists in the software engineering context at Microsoft, and should inform managers on how to leverage data science capability effectively within their teams.

The demand for analyzing large scale telemetry, machine, and quality data is rapidly increasing in software industry. Data scientists are becoming popular within software teams, e.g., Facebook, LinkedIn and Microsoft are creating a new career path for data scientists. In this paper, we present a large-scale survey with 793 professional data scientists at Microsoft to understand their educational background, problem topics that they work on, tool usages, and activities. We cluster these data scientists based on the time spent for various activities and identify 9 distinct clusters of data scientists, and their corresponding characteristics. We also discuss the challenges that they face and the best practices they share with other data scientists. Our study finds several trends about data scientists in the software engineering context at Microsoft, and should inform managers on how to leverage data science capability effectively within their teams.

Remote collaboration can be more difficult than collocated collaboration for a number of reasons, including the inability to easily determine what your collaborator is looking at. This impedes a pair's ability to efficiently communicate about on-screen locations and makes synchronous coordination difficult. We designed a novel gaze visualization for remote pair programmers which shows where in the code their partner is currently looking, and changes color when they are looking at the same thing. Our design is unobtrusive, and transparently depicts the imprecision inherent in eye tracking technology. We evaluated our design with an experiment in which pair programmers worked remotely on code refactoring tasks. Our results show that with the visualization, pairs spent a greater proportion of their time concurrently looking at the same code locations. Pairs communicated using a larger ratio of implicit to explicit references, and were faster and more successful at responding to those references.

Most modern software programs cannot be understood in their entirety by a single programmer. Instead, programmers must rely on a set of cognitive processes that aid in seeking, filtering, and shaping relevant information for a given programming task. Several theories have been proposed to explain these processes, such as ``beacons,' for locating relevant code, and ``plans,'' for encoding cognitive models. However, these theories are decades old and lack validation with modern cognitive-neuroscience methods. In this paper, we report on a study using functional magnetic resonance imaging (fMRI) with 11 participants who performed program comprehension tasks. We manipulated experimental conditions related to beacons and layout to isolate specific cognitive processes related to bottom-up comprehension and comprehension based on semantic cues. We found evidence of semantic chunking during bottom-up comprehension and lower activation of brain areas during comprehension based on semantic cues, confirming that beacons ease comprehension.

Creating and running software produces large amounts of raw data about the development process and the customer usage, which can be turned into actionable insight with the help of skilled data scientists. Unfortunately, data scientists with the analytical and software engineering skills to analyze these large data sets have been hard to come by; only recently have software companies started to develop competencies in software-oriented data analytics. To understand this emerging role, we interviewed data scientists across several product groups at Microsoft. In this paper, we describe their education and training background, their missions in software engineering contexts, and the type of problems on which they work. We identify five distinct working styles of data scientists: (1) Insight Providers, who work with engineers to collect the data needed to inform decisions that managers make; (2) Modeling Specialists, who use their machine learning expertise to build predictive models; (3) Platform Builders, who create data platforms, balancing both engineering and data analysis concerns; (4) Polymaths, who do all data science activities themselves; and (5) Team Leaders, who run teams of data scientists and spread best practices. We further describe a set of strategies that they employ to increase the impact and actionability of their work.

It is our pleasure to introduce you to the papers in this Special Issue based on the 22th International Conference on Program Comprehension (ICPC 2014).Program comprehension plays a central role in most of the phases of the software development life cycle, where it helps facilitate reuse, inspection, maintenance, reverse engineering, reengineering, migration, and extension of existing software systems.The International Conference on Program Comprehension (ICPC) is the primary venue for work in the area of program comprehension.It is also one of the leading venues for work in the areas of software analysis, reverse engineering, software evolution, and software visualization.ICPC provides an opportunity for researchers and industry practitioners to present and discuss the state-of-the-art and the state-of-the-practice in program comprehension and related areas.ICPC 2014 took place during June 2-3, 2014, in Hyderabad, India, and was co-located with the International Conference on Software Engineering (ICSE 2014).ICPC 2014 received a record number of submissions ( 76) from 19 different countries, which allowed us to assemble an excellent program that continues ICPC's tradition of providing a highquality venue for sharing the latest advances in program comprehension.The program included 20 full research papers, 11 short papers and 5 tool demonstration papers.Of these 20 full research papers, five were invited to submit an extended version to the Journal of Software: Evolution and Process.After a rigorous reviewing process with at least three reviewers per paper, four papers were accepted for publication in this special section.The paper entitled 'Framing Program Comprehension as Fault Localization' by Alexandre Perez and Rui Abreu proposes an approach, coined Spectrum-based Feature Comprehension (SFC), that borrows techniques from software-fault localization that were proven to be effective even when debugging large applications.SFC analyses the program by exploiting run-time information from test case executions to identify the components that are important for a given feature, helping software engineers to understand how a program is structured and each of the functionality's dependencies are.They present a toolset, coined PANGOLIN, that implements SFC and displays its report to the user using an intuitive visualization.The paper entitled 'Searching Crowd Knowledge to Recommend Solutions for API Usage Tasks' by Eduardo C. Campos, Lucas B. L. de Souza, and Marcelo de A. Maia presents an approach that makes use of 'crowd knowledge' in Stack Overflow to recommend information that can assist developer activities.This strategy recommends a ranked list of question-answer pairs from Stack Overflow based on a query.The criteria for ranking are based on three main aspects: the textual similarity of the pairs with respect to the query related to the developer's problem, the quality of the pairs, and a filtering mechanism that considers only 'how-to' posts.The paper entitled, 'AmaLgam+: Composing Rich Information Sources for Accurate Bug Localization' by Shaowei Wang and David Lo proposes AmaLgam+, which is a method for locating relevant buggy files that combines five sources of information, namely, version history, similar reports, structure, stack traces, and reporter information.They perform a large-scale experiment on four open source projects, namely, AspectJ, Eclipse, SWT, and ZXing to localize more than 3000 bugs and compare AmaLgam+ results with those of six state-of-the-art bug localization approaches.The study showed that the newly proposed method outperforms these existing approaches in terms of mean average precision.

Technology workers are often stereotyped as being socially awkward or having difficulty communicating, often with humorous intent; however, for many technology workers with atypical cognitive profiles, such issues are no laughing matter. In this paper, we explore the hidden lives of neurodiverse technology workers, e.g., those with autism spectrum disorder (ASD), attention deficit hyperactivity disorder (ADHD), and/or other learning disabilities, such as dyslexia. We present findings from interviews with 10 neurodiverse technology workers, identifying the challenges that impede these employees from fully realizing their potential in the workplace. Based on the interview findings, we developed a survey that was taken by 846 engineers at a large software company. In this paper, we reflect on the differences between the neurotypical (N = 781) and neurodiverse (N = 59) respondents. Technology companies struggle to attract, develop, and retain talented software developers; our findings offer insight into how employers can better support the needs of this important worker constituency.

Software is created for and with a wide range of stakeholders, from customers to management, from value-added providers to customer service personnel. These stakeholders work with teams of software engineers to develop and evolve software systems that support their activities. All of these people and their interactions are central to software development. Thus, it is crucial to investigate the dynamic and frequently changing Cooperative and Human Aspects of Software Engineering (CHASE), both before and after deployment, in order to understand current software practices, processes, and tools. In turn, this enables us to design tools and support mechanisms that improve software creation, software maintenance, and customer communication.Researchers and practitioners have long recognized the need to investigate these aspects, however, their articles are scattered across conferences and communities. This workshop will provide a unified forum for discussing high quality research studies, models, methods, and tools for human and cooperative aspects of software engineering. This will be the 8th in a series of workshops, which continue to be a meeting place for the academic, industrial, and practitioner communities interested in this area, and will give opportunities to present and discuss works-in-progress.

Code reading is an important skill in programming. Inspired by the linearity that people exhibit while natural language text reading, we designed local and global gaze-based measures to characterize linearity (left-to-right and top-to-bottom) in reading source code. Unlike natural language text, source code is executable and requires a specific reading approach. To validate these measures, we compared the eye movements of novice and expert programmers who were asked to read and comprehend short snippets of natural language text and Java programs. Our results show that novices read source code less linearly than natural language text. Moreover, experts read code less linearly than novices. These findings indicate that there are specific differences between reading natural language and source code, and suggest that non-linear reading skills increase with expertise. We discuss the implications for practitioners and educators.

The methodology of eye tracking has been gradually making its way into various fields of science, assisted by the diminishing cost of the associated technology. In an international collaboration to open up the prospect of eye movement research for programming educators, we present a case study on program comprehension and preliminary analyses together with some useful tools.

In this paper, we present the results from two surveys related to data science applied to software engineering. The first survey solicited questions that software engineers would like data scientists to investigate about software, about software processes and practices, and about software engineers. Our analyses resulted in a list of 145 questions grouped into 12 categories. The second survey asked a different pool of software engineers to rate these 145 questions and identify the most important ones to work on first. Respondents favored questions that focus on how customers typically use their applications. We also saw opposition to questions that assess the performance of individual employees or compare them with one another. Our categorization and catalog of 145 questions can help researchers, practitioners, and educators to more easily focus their efforts on topics that are important to the software industry.

Software developers make programming mistakes that cause serious bugs for their customers. Existing work to detect problematic software focuses mainly on post hoc identification of correlations between bug fixes and code. We propose a new approach to address this problem --- detect when software developers are experiencing difficulty while they work on their programming tasks, and stop them before they can introduce bugs into the code.

Background. The pressure to release high-quality, valuable software products at an increasingly faster rate is forcing software development organizations to adapt their development practices. Agile techniques began emerging in the mid-1990s in response to this pressure and to increased volatility of customer requirements and technical change. Theoretically, agile techniques seem to be the silver bullet for responding to these pressures on the software industry. Aims. This paper tracks the changing attitudes to agile adoption and techniques, within Microsoft, in one of the largest longitudinal surveys of its kind (2006-2012). Method. We collected the opinions of 1,969 agile and non-agile practitioners in five surveys over a six-year period. Results. The survey results reveal that despite intense market pressure, the growth of agile adoption at Microsoft is slower than would be expected. Additionally, no individual agile practice exhibited strong growth trends. We also found that while development practices of teams may be similar, some perceive and declare themselves to be following an agile methodology while others do not. Both agile and non-agile practitioners agree on the relative benefits and problem areas of agile techniques. Conclusions. We found no clear trends in practice adoption. Non-agile practitioners are less enamored of the benefits and more strongly in agreement with the problem areas. The ability for agile practices to be used by large-scale teams generally concerned all respondents, which may limit its future adoption.

We have met many software engineering researchers who would like to evaluate a tool or system they developed with real users, but do not know how to begin. In this second iteration of the USER workshop, attendees will collaboratively design, develop, and pilot plans for conducting user evaluations of their own tools and/or software engineering research projects. Attendees will gain practical experience with various user evaluation methods through scaffolded group exercises, panel discussions, and mentoring by a panel of user-focused software engineering researchers. Together, we will establish a community of like-minded researchers and developers to help one another improve our research and practice through user evaluation.

Software teams record their work progress in task repositories which often require them to encode their activities in a set of edits to field values in a form-based user interface. When others read the tasks, they must decode the schema used to write the activities down. We interviewed four software teams and found out how they used the task repository fields to record their work activities. However, we also found that they had trouble interpreting task revisions that encoded for multiple activities at the same time. To assist engineers in decoding tasks, we developed a scalable method based on frequent pattern mining to identify patterns of frequently co-edited fields that each represent a conceptual work activity. We applied our method to our two years of our interviewee's task repositories and were able to abstract 83,000 field changes into just 27 patterns that cover 95% of the task revisions. We used the 27 patterns to render the teams' tasks in web-based English newsfeeds and evaluated them with the product teams. The team agreed with most of our patterns and English interpretations, but outlined a number of improvements that we will incorporate into future work.

Software teams often have trouble coordinating shared work due to poor communication practices. We surveyed software engineers (N=989) at Microsoft to investigate three rarely explored aspects of coordination: (1) how an engineer's perception of dependence is predicted by his organizational characteristics, (2) how this perception differs when the dependence varies by the kinds of shared work artifacts, and (3) how the work group range affects the likelihood that an engineer will share information about work artifacts with another. Our results indicate that engineers tailor their communications about shared work for each group of intended recipients. This suggests that many existing coordination tools that rely on automatic mining and visualization of engineering activities have prevented senders from controlling the distribution of information about their work, and may have overestimated the receivers' abilities to comprehend it.

When software developers need to exchange information or coordinate work with colleagues on other teams, they are often faced with the challenge of finding the right person to communicate with. In this paper, we present our tool, called CARES (Colleagues and Relevant Engineers' Support), which is an integrated development environment-based (IDE) tool that enables engineers to easily discover and communicate with the people who have contributed to the source code. CARES has been deployed to 30 professional developers, and we interviewed 8 of them after 3 weeks of evaluation. They reported that CARES helped them to more quickly find, choose, and initiate contact with the most relevant and expedient person who could address their needs.

Enterprise software developers must regularly communicate with one another to obtain information and coordinate changes to legacy code, but find it cumbersome and complicated to determine the most relevant and expedient person to contact. This becomes especially difficult when the relevant person has transferred teams or changed their personal contact information since contributing to the project. We conducted a year-long series of surveys and interviews to help us learn how, why, and how often software developers discover and communicate with one another. In response to what we saw, we designed, deployed, and evaluated a domain-specific, IDE-embedded, photo-oriented, communication tool. We overcame a significant challenge found in long-lived projects: uniquely identifying individuals years after their contributions to the project. After deploying our tool, iteratively refining it, and deploying it again on a company-wide scale, most users reported that it simplified the process of finding and reaching out to other developers and offered them a sense of community with their colleagues, even if those colleagues did not currently work on their team. The lessons learned from our study and tool development should apply to other large, multi-team, legacy software projects.

Software engineering educators and trainers are acutely aware that software engineering graduates need strong real-world communication abilities. The National Science Foundation is supporting a three-year project in which industry professionals, CS/SE faculty, and communication-across-the-curriculum specialists are collaborating to develop curricula and teaching resources designed to improve communication abilities of CS/SE graduates by integrating communication instruction and assignments with the technical work in courses across the students' four years of study. Our panelists — an industry practitioner, a CS/SE educator, and a communication specialist — will describe what has been learned in the project's first half and invite comments, insights and advice from the audience.

Social software is built around an "architecture of participation" where user data is aggregated as a side-effect of using Web 2.0 applications. Web 2.0 implies that processes and tools are socially open, and that content can be used in several different contexts. Web 2.0 tools and technologies support interactive information sharing, data interoperability and user centered design. For instance, wikis, blogs, tags and feeds help us organize, manage and categorize content in an informal and collaborative way. Some of these technologies have made their way into collaborative software development processes and development platforms. These processes and environments are just scratching the surface of what can be done by incorporating Web 2.0 approaches and technologies into collaborative software development. Web 2.0 opens up new opportunities for developers to form teams and collaborate, but it also comes with challenges for developers and researchers. Web2SE aims to improve our understanding of how Web 2.0, manifested in technologies such as mashups or dashboards, can change the culture of collaborative software development.

The Industrial Program Comprehension Challenge is a two-year-old track of the International Conference on Program Comprehension that provides a venue for researchers and industrial practitioners to communicate about new research directions that can help address real world problems. This year, 2011, a scenario-based challenge was created to inspire researchers to apply the best "archaeological" techniques for understanding the complexity of industrial software, and foster appreciation for the delicate "anthropological" scenario which drives the behavior of the software engineers, management, and customers. Participants had two months to work on the challenge and submit write-ups of their solutions. Acceptable submissions were exhibited as posters, while the best solutions were presented during the Industrial Challenge conference session. This new challenge format gives researchers the opportunity to present their novel techniques, tools and ideas to the community.

Large-scale software engineering requires communication and collaboration to successfully build and ship products. We conducted a survey with Microsoft engineers on inter-team coordination and found that the most impactful problems concerned finding and keeping track of other engineers. Since engineers are connected by their shared work, a tool that discovers connections in their work-related repositories can help.

Large-scale software engineering requires many teams to collaborate together to create software products. The problems these teams suffer trying to coordinate their joint work can be addressed through tools inspired by social networking. Social networking tools help people to more easily discover and more efficiently maintain relationships than is feasible using one-to-one or face-to-face interactions. Applying these ideas to the software domain requires new kinds and combinations of software program and process analyses that overcome intrinsic limitations in the accuracy of the underlying data sources and the ambiguity inherent in human relationships.

In this demo, we describe WhoseIsThat, a social search portal which we built using the Codebook framework. We improve the search experience in two ways: first, we search across multiple software repositories at once with a single query; second, we return not just a list of artifacts in the results, but also engineers.

Pair programming is a practice in which two programmers work collaboratively at one computer on the same design, algorithm, or code. Prior research on pair programming has primarily focused on its evaluation in academic settings. There has been limited evidence on the use, problems and benefits, partner selection, and the general perceptions towards pair programming in industrial settings. In this paper we report on a longitudinal evaluation of pair programming at Microsoft Corporation. We find from the results of a survey sent to a randomly selected 10% of engineers at Microsoft that 22% pair program or have pair programmed in the past. Using qualitative analysis, we performed a large-scale card sort to group the various benefits and problems of pair programming. The biggest perceived benefits of pair programming were the introduction of fewer bugs, spreading code understanding, and producing overall higher quality code. The top problems were cost-efficiency, (work time) scheduling problems, and personality conflicts. Most engineers preferred a partner who had complementary skills to their own, who was flexible and had good communication skills.

Transitions from novice to expert often cause stress and anxiety and require specialized instruction and support to enact efficiently. While many studies have looked at novice computer science students, very little research has been conducted on professional novices. We conducted a two-month in-situ qualitative case study of new software developers in their first six months working at Microsoft. We shadowed them in all aspects of their jobs: coding, debugging, designing, and engaging with their team, and analyzed the types of tasks in which they engage. We can explain many of the behaviors revealed by our analyses if viewed through the lens of newcomer socialization from the field of organizational man-agement. This new perspective also enables us to better understand how current computer science pedagogy prepares students for jobs in the software industry. We consider the implications of this data and analysis for developing new processes for learning in both university and industrial settings to help accelerate the transition from novice to expert software developer.

In today's world, software development is increasingly spread across national and geographic boundaries. There is limited empirical evidence about the number and distribution of people in a large software company who have to deal with global software development (GSD). Is GSD restricted to a select few in a company? How many time zones do engineers have to deal with? Do managers have to deal with GSD more than individual engineers? What are the benefits and problems that engineers see with GSD? How have they tried to improve GSD coordination? These are interesting questions to be addressed in an empirical context. In this paper, we report on the results of a large-scale survey of software engineers at Microsoft Corporation. We found that a very high proportion of engineers are directly involved with GSD. In addition, more than 50% of the respondents regularly collaborate with people more than three time zones away. Engineers also report that communication difficulties around coordination are the most critical, yet difficult to solve issues with GSD.

Software engineers working in large teams on large, long-lived code-bases have trouble understanding why the source code looks the way does. Often, they answer their questions by looking at past revisions of the source code, bug reports, code checkins, mailing list messages, and other documentation. This process of inquiry can be quite inefficient, especially when the answers they seek are located in isolated repositories accessed by multiple independent investigation tools. Prior mining approaches have focused on linking various data repositories together; in this paper we investigate techniques for displaying information extracted from the repositories in a way that helps developers to build a cohesive mental model of the rationale behind the code. After interviewing several developers and testers about how they investigate source code, we created a Visual Studio plugin called Deep Intellisense that summarizes and displays historical information about source code. We designed Deep Intellisense to address many of the hurdles engineers face with their current techniques, and help them spend less time gathering information and more time getting their work done.

In the software development process, scheduling and predictability are important components to delivering a product on time and within budget. Effort estimation artifacts offer a rich data set for improving scheduling accuracy and for understanding the development process. Effort estimation data for 55 features in the latest release of Visual Studio Team System (VSTS) were collected and analyzed for trends, patterns, and differences. Statistical analysis shows that actual estimation error was positively correlated with feature size, and that in-process metrics of estimation error were also correlated with the final estimation error. These findings suggest that smaller features can be estimated more accurately, and that in-process estimation error metrics can be provide a quantitative supplement to developer intuition regarding high-risk features during the development process.

How do new college graduates experience their first software development jobs? In what ways are they prepared by their educational experiences, and in what ways do they struggle to be productive in their new positions? We report on a "fly-on-the-wall" observational study of eight recent college graduates in their first six months of a software development position at Microsoft Corporation. After a total of 85 hours of on-the-job observation, we report on the common abilities evidenced by new software developers including how to program, how to write design specifications, and evidence of persistence strategies for problem-solving. We also classify some of the common ways new software developers were observed getting stuck: communication, collaboration, technical, cognition, and orientation. We report on some common misconceptions of new developers which often frustrate them and hinder them in their jobs, and conclude with recommendations to align Computer Science curricula with the observed needs of new professional developers.

Agile development methodologies have been gaining acceptance in the mainstream software development community. While there are numerous studies of agile development in academic and educational settings, there has been little detailed reporting of the usage, penetration and success of agile methodologies in traditional, professional software development organizations. We report on the results of an empirical study conducted at Microsoft to learn about agile development and its perception by people in development, testing, and management. We found that one-third of the study respondents use agile methodologies to varying degrees, and most view it favorably due to improved communication between team members, quick releases and the increased flexibility of agile designs. The scrum variant of agile methodologies is by far the most popular at Microsoft. Our findings also indicate that developers are most worried about scaling agile to larger projects (greater than twenty members), attending too many meetings and the coordinating agile and non-agile teams.

Programmers who suffer from repetitive stress injuries find it difficult to program by typing. Speech interfaces can reduce the amount of typing, but existing programming-by-voice tools make it awkward for programmers to enter and edit program text. We used a human-centric approach to address these problems. We first studied how programmers verbalize code, and found that spoken programs contain lexical, syntactic and semantic ambiguities that do not appear in written programs. Using the results from this study, we designed Spoken Java, a syntactically similar, yet semantically identical variant of Java that is easier to speak. We built an Eclipse IDE plug-in called SPEED (for speech editor) to support the combination of Spoken Java and an associated command language. In this paper, we report the results of the first study ever of any working programming-by-voice system. Our evaluation with expert Java developers showed that most developers had little trouble learning to use the system via spoken commands, but were reluctant to speak literal code out loud. As expected, programmers found programming by voice to be slower than typing

Programmers who suffer from repetitive stress injuries find it difficult to spend long amounts of time typing code. Speech interfaces can help developers reduce their dependence on typing. However, existing programming by voice techniques make it awkward for programmers to enter and edit program text. To design a better alternative, we conducted a study to learn how software developers naturally verbalize programs. We found that spoken programs are different from written programs in ways similar to the differences between spoken and written English; spoken programs contain lexical, syntactic and semantic ambiguities that do not appear in written programs. Using the results from this study, we designed Spoken Java, a semantically identical variant of Java that is easier to say out loud. Using Spoken Java, software developers can speak more naturally by verbalizing their program code as if they were reading it out loud. Spoken Java is analyzed by extending a conventional Java programming language analysis engine written in our Harmonia program analysis framework to support the kinds of ambiguities that arise from speech.

Software development environments have changed little since their origins as low-level text editors. Programmers with repetitive strain injuries and other motor disabilities can find these environments difficult or impossible to use due to their emphasis on typing. Our research adapts voice recognition to the software development process, both to mitigate this difficulty and to provide insight into natural forms of high-level interaction. Our contribution is to use program analysis to interpret speech as code, thereby enabling the creation of a program editor that supports voice-based programming. We have created spoken Java, a variant of Java which is easier to verbalize than its traditional typewritten form, and an associated spoken command language to manipulate code. We are conducting user studies to understand the cognitive effects of spoken programming, as well as to inform the design of the language and editor

We present Linked Editing, a novel, lightweight editor-based technique for managing duplicated source code. Linked Editing is implemented in a prototype editor called Codelink. We argue that the use of programming abstractions like functions and macros-the traditional solution to duplicated code-has inherent cognitive costs, leading programmers to chronically copy and paste code instead. Our user study compares functional abstraction with Linked Editing and shows that Linked Editing can give the benefits of abstraction with orders of magnitude decrease in programming time.

Abstract We present the results of a detailed study of the Virtual Interface (VI) paradigm as a communication foundation for a distributed computing environment. Using Active Messages and the Split‐C global memory model, we analyze the inherent costs of using VI primitives to implement these high‐level communication abstractions. We demonstrate a minimum mapping cost (i.e. the host processing required to map one abstraction to a lower abstraction) of 5.4 μs for both Active Messages and Split‐C using four‐way 550 MHz Pentium III SMPs and the Myrinet network. We break down this cost to the use of individual VI primitives in supporting flow control, buffer management and event processing and identify the completion queue as the source of the highest overhead. Bulk transfer performance plateaus at 44 Mbytes/s for both implementations are due to the addition of fragmentation requirements. Based on this analysis, we present the implications for the VI successor, Infiniband. Copyright © 2002 John Wiley & Sons, Ltd.

A packet filter is a programmable selection criterion for classifying or selecting packets from a packet stream in a generic, reusable fashion. Previous work on packet filters falls roughly into two categories, namely those efforts that investigate flexible and extensible filter abstractions but sacrifice performance, and those that focus on low-level, optimized filtering representations but sacrifice flexibility. Applications like network monitoring and intrusion detection, however, require both high-level expressiveness and raw performance. In this paper, we propose a fully general packet filter framework that affords both a high degree of flexibility and good performance. In our framework, a packet filter is expressed in a high-level language that is compiled into a highly efficient native implementation. The optimization phase of the compiler uses a flowgraph set relation called edge dominators and the novel application of an optimization technique that we call "redundant predicate elimination," in which we interleave partial redundancy elimination, predicate assertion propagation, and flowgraph edge elimination to carry out the filter predicate optimization. Our resulting packet-filtering framework, which we call BPF+, derives from the BSD packet filter (BPF), and includes a filter program translator, a byte code optimizer, a byte code safety verifier to allow code to migrate across protection boundaries, and a just-in-time assembler to convert byte codes to efficient native code. Despite the high degree of flexibility afforded by our generalized framework, our performance measurements show that our system achieves performance comparable to state-of-the-art packet filter architectures and better than hand-coded filters written in C.