Abstract: The aim of this project outline is to describe how universities and other higher education institutions (HEIs) can work with businesses to conduct teaching projects for and with students. Both parties stand to benefit; the projects generate recruitment, outsourcing and innovation (ROI) for businesses and provide HEIs with new partners for cooperation, a source of funds, and a boost to the attractiveness of their teaching.
Keywords: Industry university collaboration, research-to-industry transfer, business model, teaching
Reference: Dirk Riehle. “The Uni1 Project (2016).” Friedrich-Alexander-Universität Erlangen-Nürnberg, Dept. of Computer Science, Technical Report, CS-2018-05. Erlangen, Germany, 2018.
The report is available as a local PDF file and on FAU’s OPUS server.
Please note that this report is a translation to English (by FAU’s Sprachendienst) of the prior report Das Uni1 Projektkonzept (2016).
As mentioned in a previous blog post, my Ph.D. students are often experienced software developers who take on the role of a chief programmer in the development of the software system supporting their research. In this work, at any point in time, each of my Ph.D. students is typically supported by 2-7 Bachelor and Master students who contribute to the system under development. Taking a long-term perspective, my Ph.D. students develop quality software rather than throw-away prototypes.
The chief programmer idea is key to making such work successful. While I usually conceive and direct the research, the size of my group has led me to let my Ph.D. students take care of any actual development themselves. (Usually…) In this role, as the chief programmer, they become the central point of coordination and integration of engineering work. In academia, this is a necessity, because an engineering dissertation is typically a multi-year project, while final thesis students, the main source of junior programmers supporting the chief engineer, are only around for six months. Thus, the chief programmer becomes the central technical hub and provider of sustained knowledge of the system under development.
Continue reading “How my Ph.D. Students Work With Supporting Students (Hint: Not Scrum)”
According to Wikipedia, “a chief programmer team is a programming team organized in a star around a “chief” role, granted to the software engineer who understands the system’s intentions the best. Other team members get supporting roles.” Amusingly, this set-up is alive and well in academia, and for good reason. At least my research group is using it and it works well for us.
Continue reading “Chief Programmer Teams Alive And Well in Academia”
When planning a publication strategy for a dissertation, invariably the question comes up where to submit your papers. Ph.D. students naturally are biased towards conferences, because if a paper gets accepted to a conference they get to travel to a (usually) nice place. I nip this bias in the bud right away: For a journal paper, every Ph.D. student gets a conference to attend for free. This lets us focus then on the economic value of a journal vs. a conference paper and how to best reap the benefits of hard research work. Here, I’m a contrarian (to most colleagues): I’m in favor of journals. It is also the economically smart choice for a Ph.D. student.
Continue reading “What’s better: Submit to ICSE or TSE? (Conference or Journal?)”
Research should be presented with appropriate choice of words to the world. So it bugs me if researchers, maybe unknowingly, overreach and call the evaluation of a theory a validation thereof. I don’t think you can ever fully validate a theory, you can only validate individual hypotheses.
The following figure shows how I think key terms should be used.
Continue reading “Evaluation of Theories vs. Validation of Hypotheses”
Last weekend, I ventured into unchartered territory (for me) and attended the Berliner Methodentreffen, a research conference mostly frequented by social scientists. I participated in a workshop on mixed methods, where the presenter discussed different models of mixing methods with each other (“Methodenpluralität” in German).
She omitted one model that I thought is often used: First to perform exploratory data analysis to detect some interesting phenomenon and then to do some explanatory qualitative research to formulate hypotheses as to why this phenomenon is, was, or keeps happening.
During my question, the temperature in the room dropped noticeably and I was informed that such exploratory data analysis is unscientific and frowned upon. Confused I inquired some more why this is so, but did not get a clear answer.
Continue reading “Is Exploratory Data Analysis Bad?”
I just returned from the Berliner Methodentreffen. One of the initiatives that was most interesting to me is a new attempt at agreeing on and standardizing an open exchange format for qualitative data analysis projects between the different QDA tools. As of today, it is not possible to take your data from one vendor’s tool to another; you are locked-in to one product. The Rotterdam Exchange Format Initiative (REFI) is trying to change that using the budding QDA-XML format.
There are three common reasons for why such an exchange format (and hence the initiative) is important.
Continue reading “On the Importance of an Open Standard Exchange Format for QDA Projects”
In our research, we often work with industry. In software engineering research, this is a no-brainer: Industry is, where there the research data is. That’s why we go there. For many research questions, we cannot create adequately, in a laboratory setting, a situation that lets us do our research.
Once a researcher realizes this, they need to decide on whether to charge the industry partner for the collaboration. Many researchers don’t, because sales is not exactly their strength. Also, many shy away from asking for money, because it is an additional hurdle to overcome, once an interested industry partner has been found.
Continue reading “Why You Should Ask for Money When Working With Industry”
I often discuss with my Ph.D. students how to structure their work and publish the results. There are many pitfalls. It gets more difficult, if we bring in other professors, who may have a different opinion on how to structure the work. Over time, I have found there are really only two main dimensions, though:
- Separate work into theory building and theory validation, and publish one or more papers on each topic
- Merge work on theory building and validation for an important aspect (hypothesis) into one and publish that
Continue reading “How to Slice Your Research Work for Publication”