Messages from Practice to Academia, Part 3: Bridge Building and Topics of Interest

This third part of my article series discusses how the research-practice gap can be overcome, identifies practically relevant topics in my research areas and encourages submissions to the “Dear Researchers” column in the Journal of Systems and Software (JSS).

Part 1 of the article series introduced the column. Part 2 discussed root causes for the gap, including goal conflicts, different ways of working, pickup problems and terminology mismatches. Let’s switch from analysis to design now and start to bridge (or fill) the gap. 😊

Keys to success for bridge building and crossing

Research results should ideally be used in industry and then continued to be developed there — assuming (and requiring) that the answered research questions match current or likely future industrial problems. There are two fundamentally different ways to get there:

• Often there is no direct, personal connection between researcher and industry professional (yet); in Domain-Driven Design (DDD) terms, they go “separate ways”. Hence, advice for this mode of operation is about technical writing and making research results visible; in DDD terms, doing so creates an open host service-conformist relation.
• However, many success stories for successful adoption and transfer come from direction collaborations aka joint work (in future posts, I plan to feature some I know of), either informal exchanges or official, funded collaborations. In DDD terms, partnership or customer-supplier relations are in place in that case. Related advice is about finding and forming such collaborations, and steps to get there.

The remainder of this section is structured according to these two collaboration modes.

Collaborating across communities

To highlight things that worked for me and/or other members of my networks, I will use a prioritization scheme from project management and requirements engineering: must have (here: essential practices), should have (making sense in many cases), could have (experimental, optional). No won’t haves here!

Must haves. Chances to succeed with collaborations increase if you:

1. Be interested in conversations and interactions with industry people. Be ready for hit-and-miss; not all initial leads can lead to concrete follow up and collaborations but over time, chances to succeed increase as your network gets stronger and stronger.¹ Clear and precise goals prevent problems later on: Should the industry partner provide a case study, participate in feasibility studies and validation experiments or become a partner to develop ideas and prototypes jointly? Sometimes, mere implementation work (in product quality) is expected, not necessarily something that is in line with research goals.²
2. Actively advertise your work and its results; do not rely on conference proceedings or journal issues to find an audience.³ Providing open access and/or freely accessible author copy PDFs (on a personal page, a public git repository or on arXiv so that it is found by Google Scholar and similar sites) is necessary but not sufficient. Unlike many universities, firms or individuals in industry typically are not subscribed to scientific publication platforms such as IEEE Xplore, ACM Digital Library, or ScienceDirect. The more channels you use, the higher the chances that an industry professional willing to collaborate will learn about your work. For instance, Rebecca Wirfs-Brock recently started to re-publish her patterns papers on her blog to increase readership (example: “Problem Frame Patterns”).
3. Make collaborations/joint work rewarding and enjoyable. An industrial collaborator will not be able to continue a collboration for long without real, genuine value to the industrial organization. Mutual respect and trust are required; it pays off to be responsive, reliable and friendly — here, there and everywhere. Be passionate about your own work and curious about the other side; expect some surprises and initial misunderstandings.²

See Eoin Wood’s “Dear Researchers” for more suggestions how to reach out to practice to find collaborators and early adopters; a previous post has a summary.

Should haves. Scoping and shaping research work adequately also helps stimulate interest in partnerships and technology transfers:

1. Look for success stories in your area and get inspired by them. For instance, certain national funding agencies call for collaborations between industry and academia. Many of them highlight projects they fund and disclose their review criteria.⁴
2. Find and read practitioner surveys reporting deficits in practice, often conducted as a first paper by a PhD student. If no such survey exists in your area, conduct one. Professional networks and communities help find participants (see below); you can also call for participation on LinkedIn. Some researchers maintain lists of people interested in participating, and are willing to share these lists.
3. Screen papers in industry tracks, journal/magazine articles or practitioner columns for problem descriptions and informal calls to action (for instance, many of the Insights columns do so). Influential paper awards often have impact on practice as a nomination criterion; look for papers that won such awards.
4. Join an existing or form a new community of people with common interest, wants and needs, ideally one with motivated people from industry and academia that are passionate about their topic and willing to invest time in an exchange. You might want to attend local meetups to get to know people. Offer talks! Presenting at industry conferences is useful for two reasons: a) you have to work out why an industry professional should care about your work to get the talk accepted and b) once accepted, you earn visibility and credibility.
5. Extend an existing tool, ideally one in a viable/active/growing ecosystem, rather than developing a new standalone one. Participating in open source projects is an option.

If you think that a practical problem is too narrow or mundane, use your abstraction-refinement skills and ask which specific instance of a more general problem it is. Having solved the general problem, the concrete solution for the original practical problem lays the foundation for the validation work (and makes great examples for research papers). See page 46 of this presentation for an illustration.⁵

Could haves. Finally, here are some more advanced moves worth considering:

1. Attend, or propose to organize, a Dagstuhl Seminar or similar event (example: Vienna Software Seminar (VSS)) that welcomes hybrid crowds. Such events are excellent opportunities to start and grow a network of industry contacts.⁶ Big names, complete unknowns and everybody else should be welcome; big names might be interested to give keynotes or other talks at regional events such as user groups, which in turn can lead to local contacts open for collaborations.
2. Try to spend some time in industry. How about a job rotation, a sabbatical, a part time job to experience how things work over there? LinkedIn and conferences are places to get in touch; do not hesitate to ask, and be both patient and persistent in your search. As a hiring research organization, look for and appreciate industry experience in addition to academic track record (fund raising, publications, citations and so on; see Part 1 for current research metrics).

Technical writing

Let’s switch over to writing about research results now.

Must haves.

1. Write research papers with personas in mind, for instance peer researcher (variants: reviewer, member of follow-up project), user of results (software engineer in practice, in a particular role across the development lifecycle), business manager and general public. What are the day job responsibilities of these personas, which techniques/tools do they use when doing their jobs? What do they know about your topic already, which metaphors will work well? When, where and how will the personas probably read about your work?⁷
2. Apply a “less is more” philosophy while writing. For instance, acronyms, jargon and unnecessarily complex sentences may cause unwelcome cognitive load for readers. Two anti-patterns in technical writing are noun stacks and zombie nouns. To empty the stack and kill the zombies, it is sufficient to turn some nouns into verbs. Example: a microservice might do an orchestration, but might as well just orchestrate. The active voice is generally, but not always preferred over the passive voice nowadays (even if the previous sentence uses the passive voice).⁸
3. Be FAIR. Findable, Accessible, Interoperable, and Reusable (FAIR) is a set of research principle(s) for digital assets and data management. Fairness also is a moral value that many ethical schools and project stakeholders appreciate.⁹ For instance: you do not want to oversell your results but provide evidence for all claims made; everybody listed as a paper author should have contributed actively; each research contribution is presented in one and only one paper.

Should haves.

1. Specify and discuss the project type of any case study used to validate research results. One way of doing so is Philippe Kruchten’s Frog-and-Octopus model. This model identifies eight project context dimensions: size, criticality, age of system, rate of change, business model, stable architecture, team distribution, governance.
2. Try storytelling. Stories, from cave painting back in the days to complex movies today usually have elements of plot, setting characters and conflict; these elements can be used in technical writing as well. This article in the journal of science communication is about telling stories to build collaborations between science communication scholars and practitioners.
3. Let ChatGPT or another generative AI summarize and reword your research paper for a practitioner audience, check the results for accuracy and post them on a personal/institutional blog or write a LinkedIn article. Tweet about it (if you still tweet).

Could haves.

1. Give your result(s) catchy names that can be memorized and work internationally. Abbreviations such as ACID, BASE and CAP can be pronounced easily, which makes them stick; some less comprehensible acronyms that I came across are MSA, SBS and SCS. See this post for more examples.
2. Try managing up. Convince your thesis advisors, institute directors, heads of faculty, etc. that you want your precious work to be found and picked up by industry short-term and in the long run, which requires extra writing and dissemination work, possibly also code maintenance later on (when things work out well). If they disagree, point them at the “Dear Researchers” column in JSS and related blog posts. 😉

Tradeoffs are involved of course; implementing these ideas comes with effort, which has to be taken off the original research work.

Calls to action

If you made it here, you probably are a researcher wanting to have an impact on practice or an industry person wanting to help researchers get there. We would like to hear from you!

Dear researchers

Titus Winters identified many practically relevant research areas in his “Dear Researchers” (Part 1 of this article series has a summary). Here are my initial thoughts on what I would like to read about in research papers and what I hope future research prototypes will support.

Software architecture. When wearing my “practitioner” hat (see previous post for a translation of the term), I often have questions in the following topic areas:

• Architectural Significant Requirements (ASRs): How to identify the requirements (context-specific, domain-specific, general) that drive the architecture design? When to prioritize which ASR?
• Most Responsible Moment (MRM) for decision making: When to make which type of architectural decision? Which ones have an early MRM, and why can they not be deferred?
• Context and entry conditions for the usage of a particular architectural style, pattern, tactic, method, notation, tool, etc.: Which requirements and context make design option A eligible? Under which circumstances is option A superior to option B?
• Impact of a decision made on certain desired qualities such as productivity (developer, end user, other stakeholders), understandability (of architecture and code) and testability. How confident can a team be that a desired quality actually improves?
• Tradeoff analysis assistants, taking multiple perspectives: short term vs. long term, local vs. global scope, external/explicit vs. internal/implicit stakeholders affected, and so on. What are the consequences (good and bad) of choosing a particular design option?
• Management and documentation: What are the cost-benefit analysis results for practices, patterns, and so forth? How do different schools of thought (e.g., agile/evolutionary vs. quality- or plan-driven architecting) differ? Which tools supporting documentation-as-code are available and how do they compare?
• Human dimension: What makes collaboration of software architects with project and product management effective and efficient? How to avoid or minimize developer tool sprawl? How to bring ethical values into software engineering and architecture design?¹⁰

Any method, practice, tool, pattern collection that helps practicing architects answer these questions will be appreciated — if it fits.

APIs, enterprise application integration, cloud. My specific areas of interest include API design, (micro-)services and cloud-native applications. Method and tool support for these areas can be improved, for instance regarding:

• API first: How to systematically derive API contracts from requirements? How to visualize API designs? How to govern API evolution and maintenance?
• Service granularity (rightsizing, decision support): When to prefer a monolith over a modulith or microservices? How small or large should the services (if any) be?
• Infrastructure as code. How can the configuration of deployment infrastructures, for instance those offered by public and private cloud providers, be supported by methods and tools? Ideally in a way similar to source code? Gregor Hohpe’s blog post “IxC: Infrastructure as Code, from Code, with Code” suggests research and development in this area.
• Managing deployment variability: How can infrastructure architectures be compared, related decisions be supported? How to provide migration/porting advice, assistance or automation, for instance in the context of serverless or other managed cloud services?
• API testing: How can API test cases be generated? How about test data on unit, integration or even system test level?

Note that I resisted the temptation to add generative AI or Machine Learning to any of these topics. This would be very well possible and, given the current interest in the topic.

Excursion: Is the following algorithm (or expression) to find research problems a pattern or an anti-pattern: my long-time core topic + latest buzzword = new research agenda item? 😉

Dear software engineers in industry

It would be great if you could become a writer! Some questions I’d like to be answered in future editions of “Dear Researchers” are:

• How would you like context and scope information for research prototypes to be specified (e.g., prerequisites for usage of methods, practices and tools)?
• What makes application examples and case studies consumable, convincing and representative?
• Which kinds of test data and evaluation make sense in your business domain and/or technical area?
• How should research results look like so that standardization initiatives can leverage them seamlessly? How can and open-source projects benefit from them?
• How to communicate design problems and solutions to them candidly and thoroughly?
• How to express pros and cons so that interest is raised, and expectations are met?
• How should the lifecycle of research results be managed?
  • Which external dependencies are ok, which ones are showstoppers?
  • Which amount of technical debt and tool/service lock in are acceptable?

Why bother? You become recognized as a published author, give something back to the community and, over time, have the chance to benefit from applied research targeting your domain and its challenges. As a side effect, you can practice your technical writing skills and learn from editors and peers while going through the process. And, as explained in Part 1 of this article series, the journal column merely looks for 2-3 pages, about 1000-1200 words.

Summary and final thoughts (all three parts of article series)

Dear researchers, please consider the following hints if you want to have a tangible impact and help narrow the research practice gap:

• Be aware of, and work towards overcoming, goal conflicts and other real-world constraints; the previous post analyses them.
• Make an effort to understand the other community and its terminology, and help those “strangers” to understand you. Differences in vocabulary cause communication problems — in software systems, in human-computer interactions and in conversations between humans.
• Work on a topic that qualifies as “I like it” and “challenging but feasible” and “relevant in practice” (and hopefully also as fundable). Find inspiration in this post and the “Dear Researchers” columns published so far.
• Apply the 18 elements of advice regarding collaborations and technical writing compiled in this post.
  • For instance, be curious and clear when looking for collaborations; scope and shape your work so that it becomes interesting and relevant for industry.
  • Make your results accessible and available to the general public, promote them actively and apply good technical writing practices such as writing for your audience (in research and/or industrial practice).
• Give and take feedback professionally, and use it to improve your research in the next cycle.

Please have a look at the “Dear Researchers” columns published so far, and consider a submission if you are in industry and would like to share your thoughts! See Part 1 and Part 2 of this article series for more information.

– Olaf (aka socadk aka ZIO)

Acknowledgements.

I thank Mohsen Anvaari, Oliver Kopp, Cesare Pautasso ,Gerald Reif, Mirko Stocker, Eoin Woods, and Uwe Zdun for their reviews and constructive criticism of earlier versions of this post.

Notes.