Messages from Practice to Academia, Part 1: New Journal Column 'Dear Researchers'

(Updated: )
Reading time: 5 minutes
Messages from Practice to Academia, Part 1: New Journal Column 'Dear Researchers'

Content Outline

The “Dear Researchers” column in Elsevier’s high-profile Journal of Systems and Software (JSS) invites industry professionals to report practical challenges and their expectations to the research community. This post reviews key messages already sent and calls for submissions.

Update (2/2026): My column co-editor Austin Henley contributes column article six, asking “Dear Researchers: Is AI all you’ve got?”. A preview is available on his blog.

Update (10/2025): Article number five reports on the results of a well-attended and productive working session with participants from academia and industry at ICSA 2025: “Dear Researchers: Think about the future, for sure, but please don’t forget about the present” (open access).

Update (7/2025): I wrote the fourth article: “Overcoming the research-practice gap: Root cause analysis and topics of practical relevance in software architecture and distributed systems” (open access), based on this post and this post. The article was discussed on LinkedIn.

Motivation

I decided to feature “Dear Researchers” in my blog — and, later on, accept the invitation to serve as column co-editor — because my experience suggests that it is needed. Let’s start with some background information on the journal (feel free to skip and jump to highlights).

Background on JSS (and scientific journals in general)

Wikipedia positions JSS as this: “The journal publishes research papers, state-of-the-art surveys, and practical experience reports. It includes papers covering issues of programming methodology, software engineering, and hardware/software systems.”

Research papers form the bulk of the journal content. Many research papers are written by PhD students, postdocs, and professors in universities; staff members in industrial research labs are among the authors as well. Before these papers can be accepted and published, they are peer-reviewed anonymously following a rather formal process. The peers review paper submissions in their spare time (as a form of giveback to the community).

The “View full aims & scope” popup on the JSS homepage lists topics of interest, including:

  • Methods and tools for software requirements, design, architecture, verification and validation, testing, maintenance and evolution
  • Agile, model-driven, service-oriented, open source and global software development
  • Artificial intelligence, data analytics and big data applied in software engineering
  • Metrics and evaluation of software development resources
  • DevOps, continuous integration, build and test automation
  • Human and ethical aspects in software engineering and developer experience
  • Software engineering for sustainability

These topics certainly are of interest to practicing software engineers, so what/where is the problem? Enter the infamous research-practice gap:

There is a significant mismatch between industry wants and needs and what is researched and published. This has been true for quite some time and does not seem to get better.

Mission of the “Dear Researchers” column

“Dear researchers” is about closing the gap (or making it smaller):

“This column will be featuring short articles from colleagues from industry where they inform the research community what really matters in industry from their perspective, and potentially make a plea to re-frame current research in a specific domain” (source: announcement).

Note the “controversial but constructive” approach that Paris and Dave, the JSS Editors-in-Chief, propose in their announcement.

Austin and I share our view on the JSS home page of the column:

We invite industry practitioners to contribute articles for the research community on practical challenges and critical success factors in technology transfer.

The column articles can be short: a few pages, around 1200 words.

Highlights from first articles in the column

The first two published “Dear Researchers” articles were:

I took away the following from Titus and Eoin:

  1. Context and relevance: Research results1 solving a problem should have a clear context, which is practically relevant. The questions they answer should have been or be asked — by professionals in industry.
  2. Users and motivation: The target audience in practice should be large, and chances of applying the research results abound. To quote Eoin, “find a software delivery team that has a problem and work on that”.2 Let me add that this team should be one that is representative for many others; a large (enough) target audience is desirable.
  3. Prerequisites: Assumptions should be founded and justified. Making them explicit helps members of the target audience to decide whether they have a chance to benefit from the research being presented.
  4. Examples and validation: Examples and validation projects should have realistic sizes and complexities. A basic “toy” case is good to motivate and illustrate — but not good enough to convince the target audience that a research result is fit and mature enough for the job. Furthermore, industrial input to the validation should be welcome and actively looked for.
  5. Availability of results: Eoin asks: “What would a practitioner need to know?” (to use the results?) and “How to you plan to publicise the work?”. You can only adopt what you find — and find relevant.

Eoin also advises inventing an imaginary team and its software if a real one cannot be found or is not available. Using such imaginary study objects to demonstrate and validate research results send a strong positive message of maturity to early adopters.3

Partly new to me, partly reassuring were Titus’s (rather broad) thoughts on what we should be studying and researching (topics): productivity, testing/defect detection, code review, prioritization/requirements planning, design, communication and collaboration, version control, dependency management, release management, and reliability.

My take followed. “Overcoming the research-practice gap: Root cause analysis and topics of practical relevance in software architecture and distributed systems” is based on two posts on this blog:

I introduce an adoption ladder in these posts and argue that the “Three primary reasons for the gap are… incentives, incentives, and incentives”. I also suggest topics of interest regarding software architectures, APIs, application integration and cloud design.

Call to action

Submissions that propose new content are very welcome. Let’s hear from the journal Editors-in-Chief again:

“We are now soliciting articles from practicing software engineers in order to transfer their hard-won practical knowledge into our academic worldview, influencing the course of scientific research for the better.”

“We encourage those working as software engineers, or even those working in industrial research who have engaged in practical projects within the past few years, to share your knowledge.”

Having clarified the “who”, they also specify the “what”:

“We would like to feature articles on open problems in the field, the struggles you encounter the most, and techniques and solutions that are not well-known in academia. This is your chance to influence the direction of research, making it more relevant for us all.”

The website for the column states:

“This column features short articles from industry practitioners informing the research community what really matters in industry from their perspective and potentially making a plea to re-frame current research in a specific domain.”

So please consider a submission if you are opinionated and/or experienced!

Framing your submission

There is no hard word limit (and no fixed submission deadline either). About 1200 words (two pages) seem adequate. How about:

  • 300 words on your role/experience and business/technology domain
  • 400 to 600 words on challenges in practice, deficits you observed and how they can be overcome, illustrated with small but tangible, concrete stories or examples
  • 300 words to summarize and conclude, ideally with a call to action for researchers.

You can simply email us, attaching or pointing at a plain text document (e.g., in Word, Google Doc, Markdown or similar).

Content matters! Austin and I will help you to revise early drafts.

The publisher will take care of layout and production editing after acceptance.

Review criteria

Our review process is informal and iterative. There is only one overarching acceptance criterion:

Does the column content have the potential to inspire researchers?

Inspiration has three levels here, forming a landing zone:

a) Inspiration to change direction (ideal/outstanding case),
b) Inspiration to improve current practices (medium goal),
c) Inspiration to better understand how/on what industry works (minimal requirement).

If you review your initial article outline/draft and the reaction to a), b) or c) is “yes”, you are on your way.

Concluding thoughts

Hopefully this post whetted your appetite for the column… please check it out at Science Directand think about a topic you can write about. Contact me if you are interested or have questions.

Let’s work on filling the research-practice gap together, so that precious resources (i.e., research staff on publicly funded projects, PhD students investing a significant amount of time and passion early in their careers) can operate more effectively in the future (as far as impact on practice is concerned).4

– Olaf

Notes

  1. “Research results” is a rather generic term; think of methods and tools, including virtual assistants, linters, transformations, generators, frameworks (and so on) for one of the areas JSS is interested in. ↩

  2. Design Science is a typical type of research that yields such results (with methods and tools etc. being designed). ↩

  3. Eoin advertised his article in a LinkedIn post (that I commented). ↩

  4. By the way, both sides have to move and leave their comfort zone to close the gap. Where is the “Dear Practitioners/Dear Industry” counterpart for the column (or where should it be placed)? 😉 ↩