Please be reminded about the January 11th, 2019, paper submission deadline for the second workshop on innovative software engineering at the German software engineering conference (SE 2019) in Stuttgart. It is a great place to meet like-minded researchers and practitioners of software engineering and its education in Germany.
I often get approached by software vendors with the suggestion that I teach a course using one of their product tutorials. There are plenty of open source databases, operating systems, and cloud computing solutions who want to make it into my curriculum. Of course, vendors don’t always call their product tutorials by that name, but use labels like college-level courses or the like, but this doesn’t change the content: They are still product tutorials. I can’t teach those and no self-respecting professor will ever do this. Let me explain.Continue reading “What Software Vendors Don’t Seem to Understand About University Teaching”
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.
Please note that this report is a translation to English (by FAU’s Sprachendienst) of the prior report Das Uni1 Projektkonzept (2016).
Thank you, Vivekanand Jayakrishnan of Zalando, for teaching us! And thank you IAV DigiLab Berlin, for hosting us!
- Theoretical Saturation
- The mental state of a researcher wanting to finish up the work and go home for the holidays.
I received five somewhat random review requests this morning, from the same journal, suggesting to me that the editor finds it hard to acquire reviewers for submissions. I pity the editor and feel bad for them (but they really should stop working for Elsevier). In any case, I five times essentially provided the same response, which is:
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.
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.
Despair not! I’ve got the goods. From my Scrum student projects (I run those day-in, day-out), here is the classic one:
I looked through the last few feature archives (the place where stories go to rest) from my student projects. Here are some fine exemplars of developer user stories. Have fun!
Teaching Scrum at University is challenging. Students are typically at the beginning of their career and don’t understand the challenges of communication and coordination in software engineering well. In a prior post on Why I Still Teach Scrum I had made a cryptic remark to that end and through various channels was asked to clarify the remark.
Scrum is a framework that needs tailoring for the specific situation at hand. The specific challenges of teaching Scrum at a University are, in no particular order, and most certainly incomplete:
- Comparatively little practical experience of students
- Widely differing capabilities as the gap between students can be large
- Transient teams as Scrum projects typically last only a semester
- Zero-Sum-Thinking by some students as to teamwork and grade