Communication Problems between scientists and computer scientists

Attendees

Matthew Habgood (Facilitator), Simon Hettrick (Scribe), Gillian Sinclair, Louise Price, Tim Parkinson, Steve McGough, David Ferguson, Gabor Terstyanszky, Elizbeth vander Meer, Tiejun Ma, Simon Mueller, Steve Wilson, Edoardo Pignotti

Overview

This session brought together scientists and computer scientists to discuss the differences in the way that these groups communicate.

Scientists frequently need to communicate with computer scientists in order to have software developed for their research. Aside from the raft of jargon, abbreviations and acronyms that computer scientists (and software development in general) use, there is a fundamental difference in the way that these groups communicate.

The communication problems topic was discussed over two sessions, and it generated two sub-sessions (Write a slide for CPOSS and Production of an e-Research pamphlet)

Conclusions and further work

Differences between scientists and computer scientists

Scientists are typically interested in getting the job done, they're not typically interested in what goes on with their software behind the scenes. Consequently, all communications should be concise and not delve into unnecessary detail.

• It was decided to investigate the possibility of training software developers (or hiring suitable software developers) to better communicate with scientists.

Make the information easily accessible

Discussions within the group made it clear that information is available, but not always easy to access. Dissemination of information is very important, and it is especially important to contact scientists who are unaware of the benefits of e-Research.

• Ask research councils to publicise the information since they have contact will a huge range of scientists.
• Prepare a series of slides for OMII-UK's users. These can be used whenever the users give a presentation and will provide an overview of what OMII-UK did for them.
• Engage in more publicity for the resources that are available
• Attend domain science events (i.e. events that are interested in the science, not those that are focussed on the use of e-Research by that science).
• Investigate the possibility of running a Q&A website, where scientists can have their e-Research questions answered by software developers.

Incomprehensible terminology and lack of background information

• To provide background to the field, it was decided to write an Introduction to e-Research guide/pamphlet. However, it was found that the eIUS project are nearing completion of such a guide (out this summer), so the creation of a new guide would be unnecessary.

• A dictionary will be developed to provide descriptions of the terms used in e-Research and Grid that are understandable to scientists who lack specialist knowledge in the area.
  • Potential dictionary entries: Authorisation and Accounting, Condor, PBS, GridSAM, e-Research, e-Science, Workflow language, Web Services, Portals and portlets, APIs, Methodology, metadata, Ontology, Grid, cloud computing, Workflow, Business process, Provenance, Middleware, Boot-strapping, SRB, VFS, VM
  • In this dictionary, it would be good to include words that are used in both science and software development, but which have different meanings in each discipline.

Make documentation clearer

Documentation should be made easier to understand by scientists by:

• Involving a scientist/user as a reviewer during the development of the documentation
• Potentially have two sets of documentation (or bilingual documentation): one that describes the software from the perspective of a software developer, and one that describes it from the perspective of a scientist.

Make software easier to use

Software should be developed so that it's easy to use. This would make it much easier to explain how to use it.

• Developing a good practice guide for software developers, which would describe how to develop software that's easier to use.