Posted by s.crouch on 17 October 2014 - 10:20am

By Gillian Law, TechLiterate, talking with Michael Chappell, University of Oxford.

This article is part of our series: Breaking Software Barriers, in which Gillian Law investigates how our Research Software Group has helped projects improve their research software. If you would like help with your software, let us know.

Sometimes you just have to recognise that you can’t do everything, acknowledge that someone else has more experience and skills than you do, and accept their help.

That’s what Michael Chappell, Associate Professor in Engineering Science at the University of Oxford’s Institute of Biomedical Engineering did, when he turned to the Software Sustainability Institute for a steer in how to take his software forward.

Professor Chappell had developed an excellent piece of software that did exactly what he set out to make it do: the C++ tool, FABBER, processes functional magnetic resonance imaging (fMRI) to recognise blood flow patterns in the brain and measure brain activity. It works well for the research group that Chappell currently leads, QuBIc, and many other developers in the field are also keen to create their own analysis models to work with it, but that’s where things begin to become problematic for Chappell.

"This bit of software had developed over time, and while I tried to make it flexible from the outset, it morphed a bit over time and I reached a ceiling of what I could do myself – I really just needed that extra bit of advice," he says.

The Institute stepped in and looked at what had been developed to date.

In order to make FABBER more useful and accessible, the team found it had to be made more modular – it needed to be redesigned to make it easier for the core functionality to be shipped as a library to other researchers who want to create their own image analysis models. Automated tests were also needed, so that modifications and expansions can be checked for bugs and for effectiveness.

The Institute developer working on the project proposed a redesign based around the notion of a core framework with pluggable components.

Interesting challenges

As FABBER is bundled as part of the FMRIB (Functional MRI of the Brain) Software Library (FSL), the team first had to identify how it had been built within FSL, and which FSL – and third party – libraries FABBER requires. A new set of build scripts were then written to extract the source code and required libraries, to create a standalone package.

The project raised some interesting challenges for the Institute, who managed to propose significant improvements to the design of the code without having any domain-specific knowledge themselves. Indeed, testing was initially challenging because FABBER had previously been tested by visual inspection of its outputs. For a developer with no knowledge of medical imaging, this was an impossible task. The developer therefore worked through FABBER’s existing tutorials to save inputs and outputs, from which he was able to write a simple test harness. After changing code he could rerun the scripts and check that the outputs were the same.

Chappell has been impressed with what the Institute was able to do, and has begun work on implementing the developers’ suggestions.

"It all fits into a bigger picture" he says. "If I can get this right, then I can go on to do similar projects. I can now take the inherent flexibility of the software and allow other people to use it easily."

The importance of collaboration

Chappell adds that collaboration is a large and vital part of his work, and if he can hand some of the development work over to his collaborators – who tend not to have the coding skillset that he does, but will be able to work with the new, easier to use versions of FABBER code – then collaborations will happen more quickly and smoothly.

He is currently continuing to manage the code in the FSL software repository, integrating any changes into the code himself, but he hopes to soon follow the Institute’s advice and use a repository such as Subversion or Git to give other researchers access, with the code synched with CVS so that any updates are reflected back in the FSL repository.

"It’s been very helpful. Helpful in that I gave them a problem that I didn’t know how to start answering, and they stepped in without a problem. There’s a big step between developing something to use yourself, and something you let loose for others to use. The Institute brought the sort of expertise that we just don’t have in house," Chappell says.

If you'd like free help to assess or improve your software, why not submit an application into the Institute's Open Call?