Reflecting on the Role and Importance of Software Conferences
I just got back from the International Conference on Global Software Engineering (ICGSE) that was held in Montreal, Canada on May 24-26. This was the first time I had attended and presented at a conference that is primarily focused on research (i.e., formal paper submission and acceptance). I was not exactly sure what to expect from the experience. I was not familiar with this conference, but I had been encouraged by Bonita Sharif, a faculty member at the University of Nebraska, to submit an Industry Talk proposal at the last minute.
I was a bit surprised by the mix of individuals there. For one, there were more people from Brazil than from the US! Additionally, there was a mix of both academic and industry professionals at the workshop. In fact, there were as many papers presented by scholars as were presented by industry people.
Overall, the experience exceeded my expectations, and I thought I would use this blog post to compare and contrast with my experiences speaking and attending industry-focused tech conferences like Microsoft Build and the Heartland Developer Conference (HDC).
Format of the Presentations at the Workshop
The workshop had about 50 attendees and was broken into five separate tracks with both research and experience presentations in each track. The five tracks were Managing Human Resources, Business Strategy, Methods and Processes, Technology, and Teaching/Skills. My talk was part of the Methods and Processes track.
Each presenter had a 20-minute slot which was moderated by someone to ensure the talking portion did not exceed 15-17 minutes. The idea was to present the topic and then leave time for questions at the end. I found this format to be very effective and, as a result, I got exposed to quite a bit of information in a pretty compressed timeframe.
Additionally, since these workshops tend to be very topic-focused, the same people are in the room for most of the presentations. This gives you the opportunity to engage and interact with folks who share a common interest. As a result, I was able to have quite a few conversations with individuals from both academia and industry throughout the conference.
Observations and Contrasts with Tech Conferences
To be honest, I was concerned going into the conference that the content would be more “academic” or deal with more basic research as opposed to addressing real-world challenges head-on. I was very pleased to see that this was not the case. In fact, I found myself thinking about the potential benefit of engaging with these types of conferences more enthusiastically.
If I had to describe the difference between this type of conference and a traditional tech conference like Build or HDC, I would say conferences like ICGSE are more focused on researching and presenting findings on real-world challenges, methods, and processes versus the sharing of technology and tools that we often see at other tech conferences. Generally speaking, one is focused on advancing the state of the art, and the other is focused on educating practitioners in modern technology.
An additional observation is that there seemed to be a general tone to the talks that feels more collaborative and inquisitive than the tech conferences. You are not left wondering whether you are getting a sales pitch like you are sometimes at these tech conferences. In fact, many of the talks concluded with the identification of further research that might be required based upon the findings.
If I had to pick an industry conference that might align more directly, I would look at something like the O’Reilly Software Architecture Conference or any number of the agile practice conferences out there. These tend to provide a variety of case study experiences, not unlike ICGSE.
In the end, I think both types of conferences play an important role. We need to have options for people with different goals and needs (e.g., learning about modern technology versus learning about the practice of software engineering and development).
I think we, as an industry, should participate in more conferences like ICGSE or ICSE or Agile Alliance XP to engage more with the research community. Doing so will allow industry to have more influence in the areas and types of research that is being done. These conferences already have industry support, but I am concerned that the support might be coming from the usual suspects (i.e., larger companies) which would mean there is less interaction between researchers and medium to small-sized companies and less influence on research with problems being faced by these types of companies.
Going Forward
I have written and spoken on numerous occasions about the problems and challenges our industry is facing and how we are falling short when it comes to education. I do not believe technology is the answer to our problems. Software engineering is not coding. Software engineering is the set of intellectual activities that occur in advance of the coding, or “manufacturing” portion of developing software. Software engineering is concerned with the “-ilities” of software systems.
As I mentioned above, I was happy to see far more industry-relevant research, information, and discussions at this conference. If this is the nature of these types of gatherings, I am more inclined to be more involved in them.
I know from past conversations that researchers in academia have struggled to engage industry partners for research. I also know that many in industry are dismissive of the research community because they don’t see obvious near-term benefits of much of the research. A solution to this problem may be for academia to be more sensitive to the need to create immediate value for industry and for industry to be more focused on the software engineering challenges, not technology/coding/manufacturing, when it comes to collaboration with academia.
Given that our profession is still relatively young and maturing, I like to look for analogies in other professions that might apply to our field. We have all been a part of conversations where we debated the merits of some particular methodology or process that has gained some traction in the field. Everyone argues for their own preference, and the debate tends to center around more qualitative arguments and intuition. No one ever really wins when folks are entrenched in their viewpoints.
I expect that there were times when this might have occurred in other fields like engineering, medicine, etc. For example, I can imagine two surgeons arguing, without any hard data, about whether their particular technique was easier to learn and perform and had better outcomes. It’s hard to imagine either becoming the standard of care based upon these informal debates. While I am no expert, I suspect that the medical field takes a more formal approach when evaluating the relative merits of alternative treatments by subjecting them to more rigorous analysis. Because of this, other practitioners can trust these evaluations and adopt the better method as the new standard of care.
Imagine if 1) more of the methodologies, processes, and techniques that have developed within our industry were evaluated rigorously, resulting in 2) these formal evaluations being trusted and accepted by the community as a whole, resulting in broader adoption of the methodologies, etc. I believe we will have reached a new level of maturity once this becomes the norm. I, for one, am hoping to collaborate with people like Bonita to work on some research that explores how we can make sound software engineering methods, practices, and patterns more approachable and adoptable by organizations of all sizes.