Better Development Tools Through User-Centered Design
Since the earliest days of computing, software development tools have been based on a dangerous stereotype: development is done by a nerd alone in a box. In fact, when one observes modern software development, it's a very social activity! Members of a development team collaborate, cooperate, and learn from one another. Even the nerdiest programmer spends as much time communicating with colleagues as studying code in an editor. The HIP group is creating new software development tools based on the obvious observation that software development is done by people working together.
The HIP Group works at the intersection of HCI, CSCW, and Software Engineering. We practice the user-centered design of software development tools. So, we spend half our time studying software development, either through controlled experiments in the lab or hanging out with developers through field studies. The other half is spent in creating new tools to help difficult situations that developers face, like being a newcomer to a team with a lot of existing code or dealing with the interruptions and task switches that break up a developer's day.
These two activities are mutually reinforcing: the studies inspire tools to build; and exploring treatments teaches us more about the problems.
In order to understand the issues that affect development work, we use a variety of methodologies to study software engineers. Although our research protocol varies from study to study, this pattern is typical:
- A short survey for recruitment and gathering initial data;
- A deep dive with a few dozen participants, for observations or interviews;
- Data analysis from the deep dive to form hypotheses;
- A large survey to test our hypotheses.
We've used this approach to study a variety of topics, discussed below.
Microsoft teams vary a lot in the distance of their members. Many teams have members that are all located nearby on the same floor of the same building, but increasingly, teams include members who work at a large spatial or temporal distance from the rest of the team.
This increased distance makes communication and coordination much harder. We're studying research questions like:
- How can we make distant colleagues seem as "real" as local ones?
- How can we spread team knowledge despite the distance?
- How do newcomers join remote teams when they lack face-to-face connections?
Developers keep a lot of critical project information only in their heads. As a result, developers' work is often blocked to look for information, and developers frequently interrupt each others' work to ask questions. This approach enjoys certain benefits, like demand-driven production of information that can be tailored to the asker's needs. However, the downsides are also significant: knowledge loss due to team attrition; slow onboarding of new team members; and productivity loss due to information seeking. To encourage better knowledge flow, we have been working on these research questions:
- What are the most difficult and frustrating questions to find answers to?
- How much knowledge can we recover from existing team artifacts?
- How can we encourage more knowledge capture without impacting productivity?
- How do newcomers to teams learn from their more experienced colleagues?
Software development is a highly collaborative activity. Developers work with people on their own team, and teams work with one another to create large-scale software products. Within teams, development is split among people of differing roles such as development, testing and requirements, and is governed by a development lifecycle, historically waterfall, but increasingly Agile. Dependencies between teams require communication, cooperation and coordination for success, but problems in any of these areas lead to conflicts. To understand how teams work well or poorly together, we are looking at these research questions:
- What are the uses of Agile methods at Microsoft?
- What are the work practices that help and hurt inter-team collaboration?
Because developers are frequently blocked and interrupted in their work, they often have to return to tasks that have been put aside, sometimes for minutes, sometimes for months. Today's development tooks place a large burden on a developer to find the documents they work on by remembering a lot of symbol names -- the names of projects, files, bug reports, classes, methods, and on and on. This memory tax means that developers spend a lot of time searching to find the documents they previously worked on. In one line of our research, we are exploring the use of spatial representations of development documents to allow developers to use spatial memory to find them. We are looking at these research questions:
- How do developers depict their code when they explain it to others?
- What are the navigation patterns developers exhibit when working with code?
- What representations of code and other artifacts best support developers' work?
Internships and Full-time Positions
Are you a PhD student looking to study software development in the beauty of the Pacific Northwest? Our group is always looking for great summer interns! To apply, you should both follow the instructions at the MSR internship page and send email to firstname.lastname@example.org to let us know your application is in the system. We look forward to hearing from you! We typically evaluate candidates in February for summer positions.
If you are interested in a full-time position, please fill out the online application. Please note that our group interviews only for research positions, and these typically require a PhD in computer science or a related discipline.
- Andrew Begel and Thomas Zimmermann, Analyze This! 145 Questions for Data Scientists in Software Engineering, in Proceedings of the 36th International Conference on Software Engineering (ICSE 2014), ACM, June 2014
- Andrew Begel and Thomas Zimmermann, Analyze This! 145 Questions for Data Scientists in Software Engineering, no. MSR-TR-2013-111, 28 October 2013
- Anja Guzzi and Andrew Begel, Faciliting Communication between Engineers with CARES, in Proceedings of the International Conference on Software Engineering, IEEE, 6 June 2012
- Andrew Begel and Libby Hemphill, Not Seen and Not Heard, no. MSR-TR-2011-136, 25 April 2011
- Patrick C. Shih, Gina Venolia, and Gary M. Olson, Brainstorming under constraints: why software developers brainstorm in groups, in Proceedings of the 25th BCS Conference on Human-Computer Interaction, British Computer Society, Swinton, UK, UK, 2011
- Andrew Begel, Rob DeLine, and Thomas Zimmermann, Social Media for Software Engineering, in Proceedings of the FSE/SDP Workshop on the Future of Software Engineering Research (FoSER), Association for Computing Machinery, Inc., November 2010
- Andrew Begel, Khoo Yit Phang, and Thomas Zimmermann, WhoseIsThat: Finding Software Engineers with Codebook (Research Demo), in Proceedings of the 16th International Symposium on Foundations of Software Engineering (FSE), Association for Computing Machinery, Inc., November 2010
- Andrew Begel and Thomas Zimmermann, Keeping up with your Friends: Function Foo, Library Bar.DLL, and Work Item 24, in Proceedings of Web2SE: First Workshop on Web 2.0 for Software Engineering, Association for Computing Machinery, Inc., 4 May 2010
- Andrew Begel, Khoo Yit Phang, and Thomas Zimmermann, Codebook: Discovering and Exploiting Relationships in Software Repositories, in Proceedings of the ACM/IEEE 32nd International Conference on Software Engineering, Association for Computing Machinery, Inc., 2 May 2010
- Robert DeLine and Kael Rowan, Code Canvas: Zooming towards Better Development Environments, in Proceedings of the International Conference on Software Engineering (New Ideas and Emerging Results), Association for Computing Machinery, Inc., 2 May 2010
Associated Research Groups
- Yit Phang Khoo, U Maryland, College Park