The Real Problem with Pay-walled Publications

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”

How Not to Ask Your Research Question (And What to do About it)

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)”

Why Software Engineering is Not Like Assembly Line Work

The other day I ran into one of the oldest software engineering tropes in the book: That software engineering should be more like work in a factory, and that developers are best equated to assembly line workers who put together a software product by assembling components to a specification. I wasn’t sure whether I should be amused or irritated. In any case, this nonsensical idea has long been debunked by Peter Naur, before it even took roots in later work by others. In Naur’s words, programming is (best viewed as) theory building, and this gets to the heart of the matter.

Continue reading “Why Software Engineering is Not Like Assembly Line Work”

Pay-walled Research Papers Do Not Constitute Published Work

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”

Inverted Research Funding

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”

ACM Hypertext 2019 in Hof, Germany

The ACM Hypertext 2019 conference will take place in Hof, Germany, on September 17-20, 2019. Here is the conference’s scope in its own words:

The ACM Hypertext conference is a premium venue for high quality peer-reviewed research on hypertext theory, systems and applications. It is concerned with all aspects of modern hypertext research including social media, semantic web, dynamic and computed hypertext and hypermedia as well as narrative systems and applications.

Regular paper submissions are due April 14th, 2019. Please submit plenty.

How my Ph.D. Students Work With Supporting Students (Hint: Not Scrum)

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)”

Chief Programmer Teams Alive And Well in Academia

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”