New Journal Column with Messages from Practice to Academia: 'Dear Researchers'

Elsevier’s high-profile Journal of Systems and Software (JSS) has introduced a column to share the perspective of industry professionals who want to reach out to the research community. This post provides an overview of the column content and explains what the editors are looking for.

Motivation for this post

I decided to feature the new column in my blog because my experience suggests that it is needed. I agree with most messages sent so far; I’ll highlight and comment some of them later in this post.

But let’s start with some background information (feel free to skip).

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 column

“Dear researchers” is about closing the gap (or making it smaller). It is positioned as this:

“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.”

Check out the announcement “Dear researchers — a new column sharing the perspective of software practitioners” (July 2024) by the JSS Editors-In-Chief, Paris Avgeriou and Dave Shepherd, for more mission information. I appreciate their intent and the “controversial but constructive” approach they propose for the column.

Articles in the column

The following column instances have been published so far:

• “Thoughts on applicability” by Titus Winters, formerly with Google and now at Adobe. Titus presents an example from ICSE 2024, on Artificial Intelligence (AI) support for requirements and issue management. The authors copy (subscription-free PDF) is available for download here.
• “Dear researchers step 1: Find a team with a problem” by Eoin Woods, Chief Engineer at Endava (an international engineering and professional services firm). Eoin brings examples from the Technical Debt conference and from ECSA/ICSA, the two leading international conferences on software architecture. The preprint paper (full PDF) is available from his website.

Key messages. I took away the following key messages, summarized in my own words:

1. Context and relevance: Research results¹ 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.”. Let me add that this team should be one that is representative for many others (to make target audience large).
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 work being presented.
4. 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?”. Rationale: you can only adopt what you find — and find relevant.

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

Eoin’s advice to invent an imaginary team and its software if a real one cannot be found or is not available is a strong and important one too (as I commented on his LinkedIn post).

Call to action

The column is fairly new still; submissions that propose new content are very welcome. Let me quote the Dave and Paris, the JSS 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.”

So please consider a submission if you are opinionated or experienced (or both)!

Framing your submission

While there is no hard word limit, 1-2 pages (about 1000-1200 words) seem adequate; the first two column instances are in that size range. How about writing about 300 words on your role and domain, 400-600 words about practical challenges, deficits you observed and how they can be overcome (ideally with small but tangible, concrete examples), and about 300 words to summarize and conclude (ideally including a call to action for researchers)?

You can simply email the editors, attaching or pointing at a plain text document (Office 365/MS Word, Markdown, Google Doc), with tables and figures being optional here. Content matters! The publisher will take care of layout and production editing.

Concluding thoughts

Hopefully this post whetted your appetite for the column… please check it out at Science Direct yourself, get inspired, and/or consider a submission!

Let’s see how things can be improved, so that precious resources (i.e., research staff member on publicly funded projects, PhD students investing a significant amount of time and passion early in their careers) can be used more effectively and efficiently in the future. By the way, both sides have to move and leave their comfort zone to close the gap.³

– Olaf (aka socadk aka ZIO)

Notes