By Thomas Ball
Thomas gave the key note at the Early Career Researchers Forum (and, as I still need at least another 30 years, given the current government, I think I’m still entitled 🙂 ).
Tom starts to talk about the two cliffs: software and science. How do we see those two – following the ideas of sir Tony Hoare. A first difference is timescale: in science it does not really matter whether some result takes a month or 10 years. It is the ambition that counts. In industry however, time matters, otherwise you don’t get paid… Another difference is idealism. In science ideals are there for their own sake, whereas in industry you need to compromise: sovle things in presence of all types of constraints. Third difference is certainty. In science you want high degree of assuredness, e.g. to be rigorous. However, in industry, you need to manage risk, again, otherwise you’re out. In industry people need to solve actual, real problem, whereas in academia, we search for more general, abstract solutions, or a unifying theory. Another idea is separation of concerns. In industry, one need to resolve a huge collection of concerns, whereas in academia, you can take time to isolate each of the problems, and inspect and grasp their understanding one by one. A key difference is originality: in academia, you need to be original, sources are acknowledged, and plagiarism is punished. In industry, you have tried and true methods: “I don’t want something original, please just make it work”. Formalization is also a key difference: years of experience like in engineering don’t count in academia: you need to proof it! So, there are many differences between science and industry, but still, we need each other!
The industrial research cycle – which seems very similar to design science 🙂 – focuses on a problem, with the scientific part in which the problem is explored, experimented and published about, but on the other hand, one needs to engineer: shut down new ideas, and realize and apply your current ideas (you published about). Science pushes ideas, engineering pulls the ideas.
Tom shows the principles based on his experience on the project SLAM (“finding bugs”) and the Static Driver Verifier: initially, they focused on exploring their ideas, and then scaled up their ideas so that it could work within Microsoft. After several years of research, the ideas had been fully “industrialized”, and added to Windows. Done?! No! Just pushing your solution didn’t work: one needs to partner up. For example, in bug finding, you need to team up with the developers to see how it actually can be used. For example: the researchers built for every step a separate tool – great for publishing – but not useful in practice. By partnering up with your intended users, you can (and have to) improve your ideas, to make them actually work: from theory to practice.
Another great example is the Everest program, where they want to verify key components in the HTTPS ecosystem. To be able to advance in this project, many researchers of different fields need to cooperate. Multi-displinary research ot really advance from science to engineering! And that’s what we need 🙂
A similar story exists for a very nice tool to learn programming for IoT: www.makecode.com. It has a language similar to Scratch, and is completely open source.