I attended the in-person version of the ICSE 2022 conference. ICSE also had an online earlier in May, but I decided to take the drive to Pittsburgh (about a 5 hour drive from home) to take advantage of the return of face-to-face meetings.
This was the first time I attended ICSE without presenting a workshop paper. (I had co-authored workshop papers for the SER&IP workshops in 2016, 2017, and 2021.) I have always been interested in watching the directions of software engineering research and practice, so it was really useful to have some informal discussions with people on the sidelines of the conference.
I learned some important new ideas in about current work in Security, and I attended several good Birds of a Feather sessions that were held throughout the conference.
Overall attendance was pretty good for both the in-person and online ICSE sessions. There were 546 people registered for main track of in-person ICSE, and 1403 people for the online conference. (Many people attended both.) And there were more people involved in the parallel conferences and other activities (ICSE workshops, Student Research Competition, and other events).
There were no keynote talks in the in-person part of the conference. All of the keynote talks were given two weeks earlier as part of the ICSE virtual conference.
The daily format for the 3 days of the in-person conference:
The ICSE conference had its usual broad range of research presentations. There has been increasing interest in Software Engineering support for Machine Learning. Diversity and Inclusion have also been investigated in many software engineering studies. Security, DevOps, Software Engineering Education, Program Analysis, and Program Repair continue to be popular areas for ICSE papers.
One problem... the presentations are so short that you don’t really learn anything in most of the paper sessions. Most of the speakers have longer video presentations on their websites, and of course, you can always read the full paper. But it is frustrating: I’m trying to recall one or two key takeaways from the conference... and the only new ideas I can really claim are from the Security session.
(There was also an excellent security paper presented by Irum Rauf from Open University. This was a paper that appeared in the ACM TOSEM journal in 2021. She and 10 co-authors investigated the possible interventions that could help development teams find security issues sooner. They concluded that an organized program of “Adaptive Security Interventions” was the best way to find and fix security issues sooner.)
(One more scary fact that I learned about security problems in shared libraries in these language-based repositories: The “average time to fix” for security vulnerabilities is 4 to 5 months.)
One of my primary goals at in-person ICSE was to share some of the results of the “Future of Conferences” survey that Steve Fraser and I ran between mid-February and early May 2022. The survey collected some data about the attitudes of people in the software conferences community to the challenges and benefits of both virtual on-line conferences and in-person face-to-face conferences. The initial report of the survey results can be found here.
Most of the people I talked to found the results to be interesting, especially the balance of communications problems in virtual and the economic and health challenges in face-to-face meetings. It is still too early to say how conferences will evolve to meet the challenges, but we agreed that there will be some room for multiple meeting modes in the future.
The ICSE Town Meeting always has interesting discussions about issues facing the conference and the software engineering research community. During the question and answer session, there was a good point about economics and access from one person at the microphone: “We can send 50 students to virtual ICSE for the cost of sending one student to in-person ICSE.” Another point about access and international participation: “Access is a two-tier system. In the US and Europe there are always good workshops that are close by, but for researchers in Buenos Aires the best opportunity to meet and interact with top folks is to travel. And, in fact, getting a paper accepted at ICSE helps a researcher to raise the funds to get a chance to travel.”
I got to see some of the value of in-person interaction during one of the conference coffee breaks. I listened to a dialog between Yu Huang (she is a new assistant professor at Vanderbilt) and Margaret Burnett (a very busy senior professor at Oregon State) – they were sharing some of their recent experiences exploring ideas for teaching computing topics to young people (grade school and high school, not college). They are both on the lookout for “patterns” of what works and doesn’t work.
I volunteered ahead of time to be the organizer of a Birds of a Feather session: “Brainstorming Ways to Make Remote Work on Software Less Onerous.” This turned into a very interesting discussion with about 25 conferees participating. The group created two lists: issues/problems with remote working and potential approaches to make remote work and remote meetings more effective.
The worst complaint in the group’s discussion: People find that back-to-back meetings kill their productivity. The most constructive suggestions were some techniques for reducing the number of meetings and allowing remote workers to have more control of their own schedules - even blocking out “no meeting days.” I particularly liked the idea of setting up relatively simple technology to support some synchronous communication among team members that need to prompt each other often. For example, three or four people who are doing design and coding work on related subsystems might choose to set up an active Zoom call – but only call out if they have a question where they need help from one of the others. For larger collaborations, a text-only channel could be better – using Slack as a simple information radiator to ask questions and get ideas from other team members in real time.
I created an initial summary of the results of the discussion: https://manclswx.com/remotework.html. This summary will be expanded to a longer report about remote work issues in software.
In addition to my own BoF, I decided to participate in three really good BoF sessions organized by others:
The Software Engineering Education session started with a simple presentation of the top challenges for universities teaching software engineering, followed by a division of the audience into small discussion groups. The main challenges are:
How do you select software projects that are interesting and compelling to the students, and how can the professors organize “giving feedback at scale?” It isn’t easy to do grading for individual or group projects in big lecture classes. And there are many students who struggle because drag their feet – they don’t start working on their programming work early enough.
Some topics are just hard to cover: open source ecosystems, continuous integration and cloud computing, design patterns, and domain-specific software engineering technologies (security, robotics, machine learning).
Our subgroup discussed a few interesting issues. We talked about the challenge of teaching more than just the naive programming practices that some students learn in high school or before. One idea that young experienced programmers struggle with is “using someone else’s software library or framework. An instructor really needs to walk the students through the thinking process involved in doing development using a framework, including how to navigate through example code and API documentation.
A couple of members of our subgroup lamented that students avoid “doing the assigned reading.” One idea for improvement was to give students small problems that use information from the reading assignments.
One of our group worked at a university that had a mandate that all students must be involved in at least one industry co-op during their time as a student. (Even history majors were required to do this – they frequently worked for a museum to satisfy this requirement.) We all liked this... There are some big learning benefits to this requirement: more experiential learning. For example, software students who get to work a little bit in industry learn a lot about teamwork and about building on top of existing code.
The last topic we discussed in our subgroup was why professors need to make their course delivery more entertaining. We agreed that a university professor has a couple of important roles in teaching software engineering – he/she needs to be a “role model” (demonstrating some important behaviors of good software professionals), but he/she also needs to be an “entertainer.” We agreed that students will do better if the design of course materials, especially recorded lectures, includes a bit of showmanship. We chatted about some of the research work about what makes certain YouTube videos popular – they found that good videos manage to capture the viewers interest in the first 30 seconds. But then we agreed that this isn’t enough for today’s students – the new model is TikTok, where the time to capture interest is just a few seconds... and it is always best to throw in a few dance moves!
The organizers of the session introduced the topic of a “Theory of Programming.” The idea is that a good overall theory of how programming works might help us better understand why programmers do what they do, and it might help researchers set up experiments to collect data to check. The organizers gave a couple of examples. For example, the Information Foraging Theory explains some of the ways that developers search for information when navigating through a code base – their actions are somewhat parallel to how animals forage for food. Another possible theory is the Automate Existing Processes theory, where developers look at the manual activities of workers and try to create automated systems that mimic the same activities.
In the Birds of a Feather session, the organizers turned around the question – instead of building up a Theory of Programming and then looking for what to apply it to, the session participants would look at applications areas in our software processes that might benefit from having a Theory of Programming, and identify some of the things we might like to get such a theory to help answer.
I joined a group discussing the area of “Code Reviews,” which is a very interesting area of software quality work. We came up with a short list of ideas and issues that we thought were important.
We came up with three key questions about code review:
Other subteams had some interesting results as well. One subteam looked at “debugging,” which they pointed out requires developers to formulate hypothesis about the behavior of code. They wanted to know “What makes code understandable?” Debugging processes can address possible mismatches in programmers’ understanding of the design, and they can also find examples of poor API design.
Another subteam looked at “refactoring.” They noted that it can often be difficult in industry to justify doing refactoring work. There are many possible reasons to refactoring: keeping the code base as clean as possible, finding potential performance improvements (such as adding parallelism), increasing the legibility of code, and creating a “minimum viable set of documentation” to guide future evolution of the code base. I suggested one more: “refactoring to understand a legacy code base” (experimental refactoring work that is usually thrown away – there is a good discussion of this in the book “Object Oriented Reengineering Patterns” by Serge Demeyer, et. al.
I had a lot of fun in the Inclusive BoF – there was a big crowd, and the organizers decided to have smaller subteam discussions about issues of organizational structure, interactions, and rules that related to inclusion.
I joined a team discussing “Code of Conduct.” I learned that there are a bunch of controversies about the existence and content of a set of Code of Conduct rules in different situations – in work environments, in events (such as conferences), and in online communities (social media and open source projects).
First, the discussion was very interesting because the circle of participants was about 80% female conferees... people with some constructive ideas about inclusion. But even the male conferees were thinking along the same lines.
Our first question got to the heart of the matter. “If your group or event has a Code of Conduct, how does it get enforced?” We immediately noted for any set of complex rules, there will be a lot of subjectivity in assessing if the rules are being followed. And of course, some rules might be “prohibitions” (things that they community will not allow) and “positive actions” (examples and models of things that should happen).
We admitted that these kinds of rules are not easy to enforce, but then we all agreed that the rules are a fundamental statement about the community and its values.
One of the participants mentioned that there is a “No Code of Conduct movement” within the open source community – and a little bit of web searching by the group discovered some ugly things about this movement. One phrase that the opponents of Codes of Conduct use to promote their movement is “We are all adults.” There are two ways to read this statement, neither of them particularly constructive:
In our further discussion, we added a few more ideas about enforcement:
The in-person conference worked pretty well, mostly because the organizers thought about giving participants multiple ways to talk to each other.
I didn’t see any official statistics about the male/female ratio at the conference. (There was a slide with the country breakdown of the paper presenters during the initial plenary session). I talked to a lot of women at the conference, and women of all ages and countries, probably a higher percentage than I have ever seen at a big conference.
We did miss one important sub-population in the in-person conference: there were very few attendees from China during the main conference – which might have to do with Covid travel rules. Even so, the number of accepted technical track papers from Chinese authors was very high – they were the number 1 country for technical track papers. (I’m sure these papers were presented in the on-line conference a couple of weeks earlier.)
I had a good conversation with a friend who works at Google. She explained that Google has done some significant productivity research – looking at the impact people working from home full-time, people working in the office a few days a week, and mixed-mode meetings. It is all internal information, but I did learn that remote productivity is highly variable (as expected), and that junior staff members had more issues with remote work. This is potentially a fruitful area for academics to start investigating individual and team productivity.
A little bit more about the “problems with mixed-mode meetings.” They decided to do all group meetings online, because it improved communications for both the in-office and the work-from-home participants.
My friend explained that her work group made an interesting change in scheduling for their group meetings. Most of her group members are back in the office two or three days per week, and they work from home the other days. Initially, management asked them to schedule their group meetings for the days when the maximum number of people were in the office. Their thought was that face-to-face interactions were clearly better.
But there was a problem with this approach. They were unable to have the entire group in the office – because some team members were working 100% remote. And those remote workers were feeling left out: it wasn’t always easy to include them in the conversations among the in-office staff. But it wasn’t only the remote workers that had a problem... The in-person attendees also had some issues. The group had developed a culture of using their online chat tools to make useful real-time side comments during the meeting. The in-office participants were frustrated because it was much more difficult for them to be part of the online chat – so the “hybrid” meetings didn’t feel as lively.
In response to these issues, they made a logical choice: they changed their group meeting time to a day when almost everyone was working from home. The results have been good... not what management expected, but the group feels that everyone in the meeting is now on an equal footing.
ICSE 2023 will be held the week of May 14-20, 2023 in Melbourne. There will be more information on the ICSE 2023 website.