People of ACM - Gail C. Murphy

March 12, 2019

Given the various subdisciplines of computing, what prompted you to pursue research in software engineering?

I entered graduate school after working for five years as a software developer. The hands-on experience that I gained building large software systems made apparent the challenges in building such systems. This was at a time when object-oriented approaches were beginning to be used more broadly to build systems. Despite the advances that objects provided in modelling the domain of a system and expressing code, there were still fundamental issues in building systems, including connecting different stages of development and in enabling reusable code. I was motivated to improve how software was built, since I had every intention of returning to industry full-time as a developer.

When I began to study software engineering, I realized that some of the assumptions that researchers were bringing to the topic did not match my experiences as a software developer. Working with David Notkin at the University of Washington, my thesis attacked assumptions that the implementation of a system would match its design (when it often did not) and that complete and accurate information about a system was needed to enable developers to make architectural decisions. We showed that it was possible to summarize the structure of a large system quickly, using tools that helped extract “good enough” information about the structure of the implementation of a system and match it to a developer’s perception of it.

My research group continues to be interested in enabling practical and scalable approaches to help software developers cope with the large information spaces they must work with to produce quality software systems.

Among the many recent insights drawn from our understanding how software engineers work, what is an especially significant realization that will influence how software is conceived and created in the near future?

Many of the tools that have been built to help software developers construct software systems focus on information from the source code, documentation and other artifacts the developers construct. For example, static analysis tools that analyze software can help a developer fix identified vulnerabilities in the code. My group, along with others, has been showing that considering how software engineers interact with these artifacts can also enable the introduction of tools that improve the efficiency and quality of development. For instance, Mik Kersten and his work on Mylar (later renamed to Mylyn) showed that capturing a developer’s interactions with code and other documents enabled the information needed for a task to be automatically modelled and captured as a task context. Once represented, task contexts could be leveraged in a variety of ways, from focusing the user interface of a development environment to predicting defects.

In Hipikat: Recommending Pertinent Software Artifacts, which won an ICSE Most Influential Paper Award, you and your co-authors introduced an approach to recommend artifacts from a software development project’s archives to help those who are newcomers to an open source project. What was influential in this paper?

This paper was written in 2003, when platforms for open source projects were making it easier for developers to initiate new projects. With the growth in projects, the challenges developers faced working on these projects were becoming apparent. As one example, it was often difficult for developers to understand the development processes being used for the design and structure of the system.

As part of his PhD project in my group, Davor Çubranić became interested in how to better support the asynchronous distributed work occurring on open source projects. He noted that open source developers lacked the ability to easily share information—as might happen around a coffee machine or water cooler when developers are co-located. He realized that one could build an implicit group memory about a project from the artifacts open source developers created as part of the development process, such as the source code, the bug database and postings to communication channels. He introduced an approach to build such an implicit group memory automatically from the artifacts of an open source development and to provide recommendations from the memory as a newcomer worked, similar to how a mentor might provide advice in a co-located working situation. Davor showed that newcomers using HIpikat could produce higher-quality code than experts without the tool. Hipikat was one of the first recommenders in software engineering. Hipikat means “a person who has opened his eyes” in the Wolof language, and the tool certainly embodies this meaning.

In your recent talk, “The Need for Context in Software Engineering,” you noted that “current tools often cause software professionals to do as much work for the tools as the tools do work for them.” How might our understanding of “context in software engineering” mitigate this problem?

It is amazing if you watch a software developer at work how much of their time is spent switching between tasks and tools. In one study we performed (joint work with Meyer, Fritz and Zimmermann), we found that developers switch between activities like coding and testing 47 (± 19.8) times per hour and that they switch between tasks 13.3 (± 8.5) times per hour. Across many of these switches, it is the developer who must cognitively transfer and interpret information. For instance, the developer might have to know which tests to run to test behavior for the code that they just changed. If we had better ways to track the context of a developer’s work, we could simplify these task switches and enable the developer to remain more focused on the task, instead of worrying about details that could be performed automatically.

Imagine that we didn’t have a notion of geo-location context in our smartphones. Without that notion, when we opened a map application, we might have to place our location on the map instead of it automatically being determined. Such a mapping application would be terrible to use. The context of our location showing up as a blue dot on the map greatly simplifies the use of the application. If we could develop more notions of context for software engineering like the blue dot on a map, we could potentially eliminate some tools used by developers and greatly simplify the usability of other tools. My group has been considering various kinds of context available in software engineering over many projects, including context from the static artifacts making up a system, from the dynamic execution of the system, from the history of changes to a system and from how individuals and teams work. By investigating the use of different kinds of context, we aim to have the tools a developer uses amplify the developer’s intelligence, improving their workflow and improving the efficiency by which a quality system is produced.