by Wojciech Kozlowski

When I completed my PhD back in 2016 and started my new job as a software engineer in London I was not planning on ever going back to academic research. I was actually quite glad that I would not have to spend my days reading dense scientific articles or dealing with reviewer comments. Things changed when in March of 2018 I attended the IETF 101 meeting.

The IETF is an open international community of network designers, operators, vendors, and researchers concerned with the evolution of Internet architecture. They meet three times a year to discuss and collaborate on technical documents that aim to influence the way people design, use, and manage the Internet. By pure coincidence the meeting I attended also happened to be the meeting where the Quantum Internet Research Group was proposed to be created within the Internet Research Task Force (IRTF). The idea of a quantum internet fascinated me and the research field quite conveniently combined my previous background in quantum optics with my newly acquired professional experience in (classical) computer networking. A few months later I handed in my resignation and in February of 2019 I joined QuTech as a PostDoc.

Looking back, the two years I spent in industry were an incredibly valuable learning experience and I have become a much better researcher as a result. My work as a software engineer was just as challenging as my PhD research on a technical level, but was of a different nature. The focus was now on delivering a robust and functional product that satisfied the customer’s requirements rather than papers, prototypes, or proof-of-concepts (though there were small teams in the company that were more experimental). My team’s product was a software control plane for classical routers and switches. That is, we developed software implementations of protocols (mostly routing and signalling protocols) that instruct the hardware what to do with your classical Internet traffic. This was an incredibly complex piece of software consisting of several millions lines of code that has been under active development for over two decades. Any system of this scale is beyond the capabilities of one person to understand. I learned a lot about the processes and methods required to develop, maintain, and continuously deliver new features in a project of such complexity.

In addition to the technical side of working in industry, it was also an eye-opening experience to see how such projects are managed. Overall, it was much more structured and carefully organised than in academic institutions. Projects would usually start with a functional specification produced by the senior engineers (such as the chief architect) together with the customer. This would be a very detailed document (possibly 100+ pages) which would precisely describe the desired product. This would then be followed by several iterations of design at different levels starting from the high-level architectural view of how the major components interact down to low-level design of the individual components. Only once the designs were reviewed (usually by multiple people) would the coding begin. Once the code was complete for a particular feature (or a set of features) it would then proceed through a rigorous testing process to verify that the final product satisfies the description in the functional specification.

When I joined QuTech I had to get used to the academic work style once again. Going back to the role of a researcher working as part of multiple loosely coupled teams having worked in an environment where every engineer’s time was carefully allocated to different projects by the management team required some getting used to. A crucial difference in a university research environment is that even when researchers work together to deliver a concrete product each academic will have their own research agenda they need to keep in mind. Everybody will have their own research questions they need to answer, papers they need to write and publish, and students will have theses they need to write and defend. Furthermore, in research there is often no “customer” to clearly define what exactly is expected. Sometimes one can consider the grant-giving body as the “customer”, but even then the deliverables are far less rigorously defined than in a typical functional specification. This is necessarily the nature research as there are many unknowns and challenging problems that have never been solved before.

Nevertheless, I tried to “import” some of the structure and processes I have learned during my time in industry into my own academic work. My first project at QuTech was to design a quantum network protocol. One of the first things I did after some initial thinking and discussions was to write a limited functional specification document. Overall, I found the exercise useful as it allowed me to share and clarify my thoughts on the subject and have others review it. However, the document quickly become out of date because I had to iterate on the overall design many times as I encountered new challenges that are a natural part of the research process. Nevertheless, I would strongly recommend the practice of producing such functional specifications ahead of any project. It provides a good opportunity to document thoughts and ideas on a particular subject in a form that others can easily review and provide feedback on before it is actually implemented.

Another process I tried to bring to QuTech and which we have already started trialling is the idea of splitting software development into a design and implementation phase. One of the projects I work on is a fairly major software project with many developers working in parallel. The idea is that we first produce the architectural design of the feature we are developing before we actually implement it. Practically speaking, a design involves a few text documents outlining the architecture and a few code files specifying inter-component interfaces. The key benefit of this process is that it is much easier to iterate on a design than a fully implemented solution. Furthermore, this gives everybody on the team a better insight into the functionality of the system and confidence that the pieces will work well together despite being developed by multiple people.

I would strongly recommend all researchers to spend a few years in industry to gain some insight into what it means to deliver a product to a customer or end-user. However, having said that, it might not be that easy to return to research as industry experience may be ignored even if it is relevant to your research area. I recently applied for an individual fellowship grant and in the rejection letter the reviewers claimed that my industry experience, whilst relevant, is difficult to judge as it did not result in any publications (the product was proprietary and closed-source). Hopefully, as the field of quantum technologies evolves and the role of industry increases the flow of researchers between academia and industry becomes a more common phenomenon.