People of ACM - Margaret Burnett

November 17, 2016

Your recent keynote address at FSE 2016 is titled “‘Womenomics’ and Gender-Inclusive Software: What Software Engineers Need to Know.” What do they need to know?

Let’s start with some simple economics. The economic success of software is coming to depend much more heavily on women’s buying choices. In fact, women make up the largest emerging market, more than twice the size of China’s and India’s GDPs combined. However, many software features work in ways that support only the problem-solving styles favored mainly by men, while few support problem-solving styles favored mainly by women. Changing such software features so that they support a wider set of problem-solving styles is a huge economic opportunity, one that can be addressed only by those in the trenches: software engineers.

Some might worry that trying to address this problem would requiring tiptoeing through a political minefield, but there are straightforward, non-political methods software engineers can follow to achieve this. My colleagues and I have been working on one such method, a software inspection process called GenderMag. You can try it for yourself. The process is freely available, and major technology companies are looking at the possibility of adopting it.

You and several colleagues have also introduced the area of end-user software engineering, to improve dependability of end users’ programs. Why is this area important, and what do you think needs to come next in enabling the paradigm to take hold in the coming years?

End-user software engineering (EUSE) is important not only because of the number of people it impacts—end-user developers outnumber professional developers by an order of magnitude—but also because it can bring useful ideas back to traditional software engineering. EUSE is about technologies that collaborate with end users engaging in aspects of software development to improve the quality of the software they shape, using programming devices like spreadsheet formulas, macros by demonstration, setting configurations, and adding customizations. Thus, EUSE approaches do not attempt to impose work practices on end-user developers; rather, they attempt to blend in seamlessly with their existing work practices.

Looking toward the future, EUSE research is at a crossroads. Aligning its work too closely to the classic software engineering lifecycle raises a risk of over-siloing the area, restricting future EUSE researchers’ vision of what can be achieved. By a silo, I mean a system, process, department, etc. that operates in isolation from others. Silos raise the risk that an area can become overly narrow, and in doing so, become disconnected from the way users really work. One strategy that can help researchers guard against such siloing is to focus on intents of end-user developers (e.g., “update my spreadsheet to meet my company’s standards”) instead of lifecycle stages (e.g., a requirements engineering tool for spreadsheets). Guarding against overly siloed thinking by incorporating more user-intent thinking can open the door to big gains that are cross-cutting and impactful, for both EUSE and for software engineering in general.

Your research seems to have strong ties to theories about people. For example, in recent papers, you and others have used “information foraging theory” to compare the approach programmers use to identify software bugs to how animals in the wild use scent to find their prey. Why is information foraging theory a useful framework for better understanding the process of finding software defects?

Yes, I’m a huge proponent of harnessing theories of how people problem-solve to inform the systems that try to support those people. The essence of theories is abstraction—mapping instances of successful approaches to crosscutting principles. In the realm of human behavior, these abstractions can then produce explanations of why some software efficiently and effectively supports people’s work and other software does not.

Information foraging theory (IFT) is a case in point. IFT was devised by Peter Pirolli and colleagues to explain and predict how people seek information. The basic building blocks are that “predators” (people seeking information) look for “prey” (information relevant to their goals) through “patches” of information (such as different files) that contains “cues” (such as clickable links) about where to find the information they want.

Such a simple set of concepts can be remarkably powerful when applied to software engineering problems. For example, together with my students and collaborators, I have used IFT to reveal commonalities among different sub-branches of software engineering research that could be leveraged toward faster progress. We have also used IFT to reveal a kind of “lower bound” in software tool usage that determines programmers’ minimum costs in using a software tool. Further, IFT-based research has revealed cross-cutting open research problems that provide opportunities to reduce that lower bound.

In short, as others such as Mary Shaw and Jim Herbsleb have also pointed out, scientific theory lets technological development pass limits previously imposed by relying on intuition and experience. I firmly believe in the importance of using theories from every applicable source we can in software engineering research. Through theories that “connect the dots” of seemingly dissimilar research projects, we can accelerate our ability to take the kinds of leaps forward in software engineering that today’s software demands.

What lessons would you pass on to aspiring young researchers in computing?

I’ve learned so many lessons along the way, but here are my best three:

1. Harness your failures. (I hope you have some to harness, because if you never take intellectual risks, you’re probably not learning much.) There’s always something to be learned from a criticism, a rejected paper, or a failed project. A failure may reveal the need for a new methodological skill, better communication of what you’re trying to do, or simply that your vision is so advanced, most of the world can’t yet grasp it. Big failures are as important to your growth as big successes.
2. Never be finished growing up. There is always someone whose intellect, skills, professionalism, or strength of character are attributes you would like to achieve in yourself someday. One of the great rewards of computing careers, whether in academia or elsewhere, is the opportunity for lifelong growth. 
3. Pass it on. Sometimes, someone reaches out a hand in a way that helps you. They appoint you to a leadership position you never expected to achieve, nominate you for an award you never expected to win, or thank you for research you never thought had made an impact. Find a way to offer helpful gestures like these to younger colleagues. Sometimes even a tiny gesture can change lives.