Effective writing is important, or you won’t be understood and achieve your goal. An example is to get the ordering of nouns (or adjectives) in enumerations right. Let’s pick an example: In software engineering, a software feature’s implementation should be correct, complete, and testable. So a project goal could be “to ensure correctness, completeness, and testability of feature implementations.”
The following rules apply:
Continue reading “On the Ordering of Nouns in Writing”
Over on Facebook of all places, I took part in a short discussion on how, as a researcher, to have an impact on practice. It is not a convenient answer, but in my opinion, if you want to have an impact, you should go into practice yourself. You can also send your students, but this creates a generational lag of research-to-practice transfer that can span decades.
One of the suggestions of how to have an impact was to perform action research. The idea is that you are creating change in an organization where you are performing said action research. However, action research is a research method whose purpose it is to help you build out and evaluate a theory. Unless you are into critical theory, action research does not have, as a primary goal, to change industry. It is just a theory building method.
Continue reading “How to Have an Impact as a Software Engineering Researcher”
Pay-walled publications are just that: Publications that nobody reads unless someone pays the publisher’s fee. I have no problem with that, because I don’t read pay-walled work and don’t consider it published research and prior art that I should care about.
The real problem starts with researchers and editors who expect me to find, read, and consider pay-walled work as prior art. That’s an unacceptable proposition to me and an unfair one to the world.
Continue reading “The Real Problem with Pay-walled Publications”
In software engineering, the structure of research theses, most notably dissertations, is straightforward: (1) Formulate a research question, choose a method, build a theory, then (2) generate at least one interesting hypothesis, choose a method, and test the hypothesis as part of the theory’s attempted validation. A dissertation can do both parts 1 and 2 or just one of them, relying on or leaving stuff to others. The benefit of this structure is that it will be easily recognized by other researchers and make it eas(ier) to write great papers.
Continue reading “How Not to Ask Your Research Question (And What to do About it)”
I just had another discussion with a reviewer (by way of an editor) who insisted that I cite (presumably their) work buried behind an Elsevier paywall. How obnoxious can you be?
It is 2019 and there are still editors and reviewers who consider articles, which are not freely accessible on the web, published research? That’s so wrong. Such work has been buried behind a paywall. It yet needs to be published.
Continue reading “Pay-walled Research Papers Do Not Constitute Published Work”
Most people believe that scientists first perform basic (“fundamental”) research and then perform applied research. Basic research delivers the fundamental insights that then get detailed and refined as they hit reality in applied research. Along with this comes the request that basic research funding should be provided by the country (because few companies would ever pay for it) before industry kicks in and supports applied research. Nothing could be further from the situation in my engineering process research.
Continue reading “Inverted Research Funding”
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?)”
When teaching about modeling the world, I often talk about how concepts should be MECE, that is, mutually exclusive and completely exhaustive. I didn’t invent this acronym, I took it from Barbara Minto’s writings about structured reasoning.
I finally figured out the appropriate German translation, and, oh wonder, it is shorter than the English version. It is:
Überlappungsfrei und erschöpfend.