ICSE 2017 trip report: people, process, and program analysis
My first International Conference on Software Engineering was in 2005 in St. Louis, twelve years ago. My undergraduate mentor Margaret Burnett had recommended I start publishing beyond HCI venues, and she recommended I give ICSE a try.
Even just 12 years ago, the conference was quite different. It was smaller, for one, with just 44 research papers compared to the more than 78 papers published this year. But more noticeably, the balance of topics was quite different. In 2005, all except five papers (one of them mine) focused on novel tools or evaluation of tools. My work, which focused on developers’ inefficient use of IDEs, was a rare breed.
In contrast, this years’ conference contained a dramatic diversity of contribution types, including literature reviews, grounded theory field work, dozens of empirical studies, and experiments on software process. The usual tool contributions were there of course, but even those were different from twelve years ago, as many leveraged large data sets that represent traces of developer activity. In just a decade, software engineering research has shifted from primarily algorithmic contributions to ones spanning empirical techniques to social science theory.
Perhaps the most notable shifts were in the keynotes. Moshe Vardi, a complexity theory researcher, ended his talk calling for a theory of why some SAT problems are hard and why some are easy; this is not a complexity question, but an empirical one. Daniel Jackson, who studies formal methods, also gave a keynote, and ended his talk calling for a deeper understanding of the human factors surrounding formalism, reflecting on his struggles to help students, developers, and companies reason about formalism. Mark Milinkovich, Executive Director of the Eclipse Foundation, argued strongly for the view that excellent open source communities aren’t about excellent code, but excellent governance, infrastructure, process, IP management, and marketing.
As I discussed these talks with attendees, there was clear acceptance that these were fascinating, foundational questions, but also that much of the community was ill-equipped to investigate them, since they demanded methodologies far outside conventional computer science.
That doesn’t mean the community isn’t trying. Rashina Hoda and James Noble presented a study on how teams succeed and fail to adopt Agile, contributing a new theory of process transition. Amiangshu Bosu, Jeff Carver, Christian Bird, and others presented a paper on how on the social dynamics of code review, finding that most of the benefits are non-technical (dissemination, relationship building, impression formation), and that most of the challenges with code review are non-technical (ensuring high-quality writing and facilitating program comprehension). Other studies in the Software Engineering in Practice track and co-located investigated social dimensions of software engineering, including the surprisingly positive impact of more rapid releases on work life balance, the challenges of adapting scrum to distributed development, and the dominant challenges in software engineering capstone courses being coordination, not programming. Both of my papers on software evolution decision making and on cross-disciplinary collaboration also focused on social interactions.
One of the most interesting discoveries was by Todd Sedano at Carnegie Mellon. His paper was titled “Software Development Waste”. Todd conducted a participant observation, developing a grounded theory about the kinds of waste that exist in software engineering. These include building the wrong thing, mismanaging the backlog, rework, unnecessary complexity, extraneous cognitive load, psychological distress, waiting and multitasking, knowledge loss, and ineffective communication, all effectively resulting in effort that does not drive project progress. The work contributes an exciting taxonomy for understanding productivity at the individual, team, and organizational levels.
Of course, I spent most of my time talking to attendees, not attending talks. I had a fascinating conversation with Martin Robillard about our inability to anticipate dramatic change. I spoke with two students from Germany about some of the foundational challenges in machine learning configurability. I grilled Caitlin Sadowski about Google’s internal practices for supporting developer learning, which apparently include a centralized team to write tutorials, decentralized tutorial writing by teams, documentation generation tools, resource discovery search engines, and lots of informal social learning.
And of course, Buenos Aries was beautiful and tasty.
