My research interests cluster around the following areas:

Research Software Engineering & Software Engineering Research

The engineering of software for science – research software engineering – comes with distinct and unique challenges. For example, the domain knowledge required for science often sets a (very) high technical bar for software engineers to understand the respective software requirements for scientific problems in that domain. Then, too, the nature of requirements is different: for ‘mainstream’ software, there are identifiable customers and other stakeholders for which one can specify requirements, such as user stories. Phrased another way, it is the customer or stakeholder who decides on the requirement. Whilst there are scientists, and therefore users of scientific software, the end-user is, in some sense, science, not the scientist. Furthermore, since science often advances through replacing one model with a subsequently more ‘correct’ model (e.g., replacing the Ptolemaic model of the solar system with the heliocentric one), requirements for software may legitimately become deprecated.

This raises many questions, for example:

• How does the engineering of software for science – research software engineering - compare to the engineering of software for ‘common applications’ known to the general public, e.g., retail sites, websites?
• How can Research Software Engineers (one kind of Research Technical Professional) co-inquire on these challenges with Software Engineering Researchers?
• How do technical challenges (e.g., testing) and cultural challenges (e.g., culturally accepted practices) affect each other?

Such questions quickly reveal related concerns, e.g., with tensions between the cultures of science and software engineering, and differences in requirements specification and change, in architecture and design, in testing and quality assurance, code and data management, refactoring, technical debt, coding conventions, performance, and sustainability.

Story thinking and computational thinking

Story thinking and computational thinking are two contrasting – even, at times, opposing – ways of thinking about the world. I am interested in what we can learn from comparing these ways of thinking and, taking this further, in what ways we can bring these ways of thinking together.

Amongst other ideas in this space, I am interested in:

1. How software engineers and writers think as they work on and with their respective artefacts, and what software engineers and writers might learn from each other. For example, we’ve (a colleague and I) taken a technique from safety software engineering and applied that technique in two recent workshops, one with professional writers and one with emerging writers, as they "workshop" each others' stories, in groups.
2. The mental models used by writers and software engineers, and how those relate and contrast, and how they affect and are affected by modes of thinking. For example, we’ve begun to explore how computational models “de-mean” stories, using a very simple and well-known six-word story ("For sale. Baby shoes. Never worn.") and two "stories" from computer science to explore these issues. Looking ahead, we want to investigate whether and how stories might help software engineers develop software in a more responsible way, for example, using larger stories, such as memoirs.
3. The language used by writers and software engineers, and how that affects, and is affected by, their thinking and their models.
4. Software engineering makes considerable use of story-like representations, in particular the user story and the scenario. We are also investigating the extent to which the user story and the scenario "satisfy" the criteria for a story; and, together with this, are investigating the extent to which software engineering has grounded its concepts of story in the narrative disciplines.
5. What can we learn from story thinking for our understanding of Artificial Intelligence.

Case study research in software engineering

I co-authored the first discipline-specific book on case study research in software engineering (in 2012). More recently, I've investigated, with a colleague, the extent to which researchers are accurately reporting their primary studies as case studies (in about 50% of studies they are misreporting studies as case studies) and the extent to which secondary studies are accurately reporting others' primary studies as case studies (these results are under review, nevertheless the results are very disappointing for the discipline...). We developed (yet another) checklist to help researchers assess whether their's and others' studies are in fact case studies; and have developed a trivial "indicator" to quickly detect whether an already-published paper that claims to be a case study is in fact a case study. The indicator has been implemented in code. The results of our analysis suggest the trivial indicator outperforms human "classifiers".

Research "citizenship" and collegiality

In addition to my own research interests and aspirations, I also want to help others. This has been through line management, formal mentoring, coaching, supporting as a co-author or co-supervisor, assisting researchers at risk from other countries, and co-facilitating several leadership development courses, together with Professor Geraldine Fitzpatrick, and in conjunction with Informatics Europe.