This was originally posted on the blog Distant Whispers from an Academic Engineer's World.
Most of us, in the field of computing, like to believe we are good team players. This seems not just the politically correct line, but also makes our work feel more enjoyable [1]. I am encompassing in my discussion a fairly wide swath, those who are in research, both academic and industrial, in the broad field of computing.
The question is does this also lead to the most productive outcomes? Does this lead to algorithms that have the greatest impact? Does this lead to computing systems that have the greatest uptake? I will take a peek at the history of computing to see if the pioneering early developments were also the results of team effort. I will give you my opinions and then give you some arguably cherry-picked statistics behind my opinions.
Team Work at the Dawn of Computing
We have a romantic picture of a splendid genius who toils by herself and comes up with an age-defining invention. That romantic picture has been built up through many history lessons — Archimedes jumping up from his bath having discovered the laws of buoyancy, or Newton being bonked on the head to realize the laws of gravitation. Apocryphal some of these incidents may be, but they have a powerful hold on our imagination.
Now jump forward many centuries to the dawn of modern computing. It is the 1930's and 1940's. There is a race to create a truly programmable computing device breaking free from the tyranny of mechanical gears and pulleys, to create a fully electronic computing machine. For many of us who work in computing, the names of Presper Eckert and John Mauchly are instantly recognizable as early pioneers, the ones who made ENIAC happen, the first electronic computer unveiled at the University of Pennsylvania in 1946. The German inventor Zuse and the Iowa inventor Atanasoff are forgotten names. They are forgotten for several reasons: Zuse because he was in Germany as it was being pummeled in WWII, and Atanasoff did not quite get it working before he left to server in the Navy. But to me, an important reason is that they did not get a team working behind their brainchilds.
Mauchly and Eckert, on the other hand, soaked in ideas from everywhere [2] and got a team to work together to get a functional, fully electronic computer. Across the pond, in Bletchley Park too, it was a closely knit team that put together the working Colossus computer to break German codes, though it was shrouded in secrecy and therefore possibly its impact was less powerful, at least in the near term. It was a team effort that delivered the Colossus, and by a stretch, victory in WWII, though Alan Turing is its highly visible embodiment today.
Academia and industry
A long-held belief was that in academia, research and development in computing are more of an individual effort, while in industry, this is more of a team venture. I think at a broad generalization, this was true earlier and is still true now, but less drastically. Of course, tech giants can have many engineers work intensely on a problem that has been identified to be of immediate market need.
But let us look at a domain where the two are roughly comparable, mid-term research and development. It was historically true that in academia it would be a professor working with a researcher from her team or a small group would move ahead, often in steps that would appear glacial to the outside world. Now it is much more common for teams of multiple faculty members, within an institution commonly, and sometime across institutions, working collaboratively on a problem. In industrial research organizations, an overwhelming majority of my colleagues, work in teams, as the projects are usually a part of an ambitious plan to bring something revolutionary, or at least starkly novel, to the marketplace.
Publications tell the story
Over the history of Computer Science, the number of authors per publication has increased quite consistently [WWW1, WWW2]. This is in line with what has happened in other fields. And this increase is explained not just by computing becoming more of a team sport. There are several other compelling factors such as the dramatic improvement in the electronic means we use to collaborate — think how your desire to collaborate will be lessened if you did not have free, high-quality video conferencing at your fingertips. Nevertheless, I feel that over the years as Computer Science has matured, the lesson has dawned on many of us that the hard problems that need solving have been getting harder and needing a variety of technical skills. Ergo, a team, not an individual sport any more.
In the field of Machine Learning [3], as I look upon the papers that have had great influence within the field and far far beyond, I list the following.
- "Generative Adversarial Networks" NeurIPS 2014: 8 authors
- "Faster R-CNN: Towards Real-Time Object Detection with Region Proposal Networks" NeurIPS 2015: 4 authors
- "Adam: A Method for Stochastic Optimization" ICLR 2015: 2 authors
- "Deep Residual Learning for Image Recognition" CVPR 2016: 4 authors
All, including the Adam paper, had people from multiple groups or multiple PIs. Did anyone say team effort?
Now casting my eyes closer to home — in the area of computer systems. The crowning jewel conferences are SOSP and OSDI, and the test of time award papers represent the best of the best, with the additional shine that they have had influence over time. Given since 2016 to 1-2 papers, in the last 5 years, the average number of authors per paper has been 7.8 [4]. Instructive that looking at the 5 years before that [5], the average number is only 2.63. So, the pendulum is in favor of playing as a team, and the pendulum has been swinging in that direction quite significantly over the last few years.
In Conclusion
Research in Computer Science has been getting to be increasingly a collaborative effort. Personally speaking, I love this. I no longer have to be a jack of multiple areas as I try to solve some towering problem. And it is simply more enjoyable to be working with collaborators with different technical skill sets, though the start of such an effort often resembles the Tower of Babel. For those who like to fly solo, there is room too, just dazzle with the sheer brilliance of your idea.
[1] Of course, there are exceptions to any rule. There are those, and that constitutes a significant minority, who like to work on their own and the big tent that computer science is does have a place for all such.
[2] This can be problematic from a legal patenting standpoint as did happen in this case with a long drawn out saga of litigation between Atanasoff with Honeywell versus Eckert-Mauchly with Rand Sperry. Read all about it in the wonderful book by Walter Isaacson called "The Innovators: How a group of hackers, geniuses, and geeks created the digital revolution", Chapter 2.
[3] Which I dabble in, mainly to apply its fruits to systems and security.
[4] The Chubby paper by Mike Burrows, a single author paper stands out as a towering exception. Single author papers are the rarest of rare breeds and a single author paper to have had this much influence in this age is a testament to what an incredibly cool idea it is.
[5] These are marked as notable papers, not test of time award winners.
Saurabh Bagchi is a professor of Electrical and Computer Engineering and Computer Science at Purdue University, where he leads a university-wide center on resilience called CRISP. His research interests are in distributed systems and dependable computing, while he and his group have the most fun making and breaking large-scale usable software systems for the greater good.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment