Practical recommendations for developing software for life science applications Free

Research software enables unprecedented levels of automation and reproducibility in quantitative bioimage analysis. However, the discipline gap between tool developers and life scientists is often wide, hindering the utilisation of software to its full capacity (Schlaeppi et al., 2022). To bridge this gap, the specialisation of bioimage analysts has emerged. These analysts develop software tools for set tasks and devise quantitative workflows that leverage existing research software tools to address specific biological questions (Cimini et al., 2024). Owing to their pivotal role, bioimage analysts are required to develop effective communication skills to facilitate collaboration and understanding between both communities (Fazeli et al., 2024 preprint).

In addition to effective communication and domain-specific knowledge, the successful development and adoption of bioimage analysis software relies on software development good practices (Nowogrodzki, 2024). A structured approach to software development, namely the software development life cycle (SDLC), provides a systematic framework that guides developers through the phases of planning, designing, implementing, testing and maintaining software. By adhering to these phases, developers can ensure that the software meets the specific needs of biologists and experimentalists, while also being robust, reliable and user-friendly.

From our experience as bioimage analysts, we have realised how difficult it can be to develop research software that can be successfully utilised by experimentalists and microscopists. Therefore, in this Essay, we propose a structured process inspired by the SDLC framework (Fig. 1; Fig. S1) and a short list of recommendations specifically targeted to developers and bioimage analysts who are new to creating image analysis software for biological applications. These recommendations aim to mitigate the challenges posed by the interdisciplinary nature of software development for bioimage analysis, and to enhance the usability and uptake of new software, ultimately leading to more efficient and accessible tools for the life science community.

To showcase the development process of user-friendly bioimage analysis software, we use two case examples previously developed by us: Fast4DReg (Pylvänäinen et al., 2023) and Alignment by Fourier Transform (AFT) (Marcotti et al., 2021). Fast4DReg is a Fiji plugin for correcting sample drift and performing image registration, whereas AFT is a tool to quantify the alignment of fibrillar features in bioimages that is implemented in Python and MATLAB.

The development of bioimage analysis software begins with a clear identification of the problem that the software aims to solve, a good understanding of how the new tool compares with existing tools for similar tasks, and the establishment of targeted requirements. Although ease of use is essential for specific applications, adaptability can broaden the appeal of software without compromising its primary focus. The design should prioritise simplicity, concentrating on excelling at a single task. This approach enhances readability of the documentation, improving user experience and facilitating debugging or further development.

Software development should start with identification of the specific purpose of the software and why similar already available tools are insufficient for the task at hand. This should be followed by establishment of requirements for the software, from both the user's and the developer's perspectives (Levet et al., 2021). These requirements should include the expected input data to be handled (for example, single timepoint versus time-lapse data, single versus multiple channels) and the platform to be used for dissemination of the software so that it successfully reaches the target audience (for example, a Fiji plugin or Python code), together with some more general requirements, such as the need for accessible graphical user interfaces (GUIs), batch processing or graphics processing unit (GPU) acceleration solutions.

Once these requirements have been established, it should be kept in mind that the tool should be simple, so that it excels at one task as opposed to performing many tasks in an average manner. This consideration applies to both the algorithm and the provided output. A simpler algorithm will be easier to document and debug, while a clear and straightforward output will provide a more intuitive interpretation of results.

End users, such as experimentalists and microscopists, might be unfamiliar with coding and are often intimidated by the requirement of using the command line to interact with analysis software (Carpenter et al., 2012). Therefore, if aiming to develop software for life scientists with limited coding experience, the starting point should be an accessible and user-friendly GUI, which lowers the initial barrier to using the tool. The GUI should be simple, self-explanatory and serve the purpose of communicating to the user what input is expected from them. If more complex parameters need lengthier explanations, these should be extended in the software documentation.

Users also tend to generally distrust automated tools at first. Therefore, providing a visual output that allows them to evaluate performance on their data is crucial, so that they can assess whether the analysis has been successful and reflects their expected outcome. This visual assessment can be represented by overlays on the raw images, heatmaps or similar visualisations.

It is often better to reduce the number of parameters, as opposed to giving users the flexibility to tune everything in the code. The developer should keep in mind the primary goals of the software and, based on this, decide which parameters would be relevant for the user to modify. These parameters should be connected to physical, quantifiable entities (for example, length), making them easier to initialise and understand.

In some instances, it can be relevant for users to explore the parameter space by visualising the output while modifying the parameters within given ranges. If this is the case, consider implementing such parameter search functionality within the code.

Image analysis software tools are typically developed for a specific application and a particular type of input data. However, with small adjustments, a tool can often be generalised to accommodate other input types, thus making it appealing to a wider user base. It can also be considered whether the software could be adapted for analysing different biological samples, or images acquired with a different magnification or acquisition modality.

The counterpoint to this suggestion is that care should be taken not to be overambitious with what the tool can achieve (see ‘Keep it simple’ above). Rather, it can be more beneficial to document the limitations of the software, and which input types and applications might be outside its remit.

User-friendliness is essential in bioimage analysis software, as the end users are often experimentalists without extensive knowledge of coding and with limited time available to figure out complicated software. To ensure that the tool is intuitive and accessible, it is important to involve potential users early in the development process, as they can provide valuable insights into the usability of the software, helping to refine its interface and documentation. Providing example datasets is equally crucial, as this allows users to quickly learn the software and understand its applicability to their data, and facilitates software benchmarking against other tools. By addressing these aspects, the software becomes more approachable, increasing its adoption and effectiveness for the research community.

One important point to keep in mind when deploying a software tool to a wide audience is ease of installation. In fact, particularly when developing software for end users who might be unfamiliar with coding, installation tends to be the bottleneck to actual usage of the tool. If installing a tool requires specific preparatory steps (such as creation of a Python environment), these should be clearly defined and explained in the documentation, and further resources should be highlighted when needed. Consideration should be given to providing installation builds where possible, and installation should be tested on different operating systems to pre-empt possible hurdles.

Research software tends to have a short lifetime, and the temporary nature of academic contracts exacerbates the issues around long-term software maintenance. Planning for easy maintenance that can be performed by people other than the original developer is key to keeping a tool running for as long as possible. Principles of clean coding should be followed to this aim, with particular attention to modularity, human-readability, open access and clear execution flow (Schölzel et al., 2021).

Research software development is often a lonely process where the developer and tester are the same person (Levet et al., 2021). In such cases, the developer may become immersed in the software and might not recognise limitations or annoyances that could hinder its usage.

Seeking input from (bio)friends and colleagues to test the software, offer feedback on usability, enhance documentation, and provide examples and online tutorials can lead to valuable improvements in the software. We therefore recommend identifying several people who might be interested in the development or application of the tool and who are available to test it at different phases of development. Additionally, feedback can be acquired during workshops and hackathons, or whenever users are attempting to use a tool for the first time.

To accelerate software testing, we have found that providing example open access datasets is crucial. This allows users to assess whether their expected datasets can be analysed with the software or to understand what type of images can be analysed, and allows testing even if the user do not currently have access to suitable input data. Test datasets are also fundamental for developers for benchmarking their tools against similar available software (Kozubek, 2016). Additionally, video and written tutorials can be prepared using these datasets, to aid prospective users in adopting a software solution.

Knowledge dissemination is a vital phase in the development of bioimage analysis software, ensuring that the tool reaches its intended audience and is effectively used. Clear documentation plays a key role by providing guidance for users and developers in understanding installation, usage and software features, fostering transparency and reproducibility in the research community. Additionally, discussing the software throughout its development and presenting it at scientific events – ideally with engaging examples – increases memorability of the software in an already crowded bioimage analysis software landscape (Haase et al., 2022), and attracts potential users and collaborators. Finally, the FAIR principles (Findability, Accessibility, Interoperability and Reusability; Wilkinson et al., 2016) should always be kept in mind when developing new tools.

Well-written documentation is crucial for making software usable (Carpenter et al., 2012). Documentation should cover installation steps, software usage, applicability to different input data and imaging modalities, and software limitations, and it should provide workflow examples. It should be written in such a way that different audiences can benefit from it, aiding both users and developers in comprehending, replicating and even expanding the software for analyses performed on their applications.

Adequate documentation ensures transparency, reproducibility and collaboration within the research community (Carpenter et al., 2012). For this reason, it might be useful to conceive documentation in various formats, such as ‘readme’ files associated with code repositories, dedicated software websites, online tutorials and accompanying methods papers.

Dissemination of knowledge of the developed software is essential during and after its development. During the development phase, talking about the software will attract possible test users who may provide valuable feedback and end users that might benefit from the software. Moreover, fellow developers can provide tips and tricks to overcome possible challenges. When the software is ready to be tested, we recommend bringing it up in meetings and open software lounges, as well as writing blog posts about it (for example, on FocalPlane; https://focalplane.biologists.com/) and announcing it on relevant community forums such as image.sc (https://forum.image.sc/).

Related to the previous point, we have found it helpful when presenting tools at meetings and open software lounges to bring up funny examples, such as unexpected input images (such as dog fur instead of cytoskeletal fibres). This tends to make the presentation more memorable, especially for applications where many tools are available. A catchy and memorable name for the software tool is also advisable, and the utilisation of funny debugging and user messages can also be considered to make the software experience more relatable.

Open-source software has played a key role in the past few years in widening the audience of automated and unbiased computational tools for bioimage analysis. In addition to the fact that open software is typically free of financial costs, providing licensed access to the source code enables better transparency, reproducibility and standardisation (Levet et al., 2021). We therefore recommend that the developed image analysis software tools are made open access by default, and that developers consider the use of permissive licences (such as the Creative Commons CC-BY licence) for easy re-use and dissemination (Haase et al., 2024 preprint).

We also recommend that all of the FAIR principles are taken into consideration when developing software tools. We believe that following the suggestions discussed in this work would already be a good starting point to achieve FAIR-ness: making the tool open-source software, documenting it properly, testing it extensively and discussing it with different audiences would all be helpful actions in this direction.

Fast4DReg (Pylvänäinen et al., 2023) was developed to address the needs of researchers working with challenging three-dimensional (3D) time-lapse videos that suffer from axial and lateral drift, thus complicating their downstream analysis. At the time, the drift correction tools available were limited by low processing speed, difficult parameter optimisation and the need for manual file-by-file corrections. Fast4DReg significantly accelerates processing times by using intensity projections instead of correcting drift in the 3D space, and it allows intuitive parameter optimisation and options for batch processing. We divided the process into two steps: estimation of drift and application of drift correction.

Fiji was selected as the platform for Fast4DReg as it is the point-and-click software type used most by life scientists (Jamali et al., 2022). An intuitive two-step GUI for drift estimation and application was created to lower the threshold to start processing the data. We extracted the original two-dimensional drift correction function used in NanoJ (Laine et al., 2019) as an independent macro-recordable function that can later be integrated into a new piece of software, allowing researchers to create workflows for their specific purposes.

During Fast4DReg development, most troubleshooting was conducted by fellow researchers who were in urgent need of the tool. This process provided valuable information, such as identifying software bugs and correcting the illogical order of commands, which was then used to enhance the tool. For example, the need for batch processing of multiple files arose from our group members who wanted to apply the same correction parameters for multiple images. Inspired by this, we further improved Fast4DReg to process multiple image files in a batch and export a settings file that could be applied to other datasets with similar drift (for example, other channels). To do this, we incorporated a code that saves the correction parameters as a csv file, which can then be applied to another dataset. To avoid overwriting the drift correction results, we implemented an option whereby a user can give a unique identifier to the correction parameters used. This feature prevents accidental overwrites and allows retracing of steps back to the specific settings employed, enhancing reproducibility and traceability.

We decided to publish all image data used in the publications in properly annotated dataset-specific Zenodo repositories (https://zenodo.org/records/7514913) and provide detailed documentation as a readme file in the software repository (https://github.com/CellMigrationLab/Fast4DReg). To ensure findability, links to the data repositories and to existing datasets elsewhere were included in the original publication and in the software repository.

Knowledge of Fast4DReg was disseminated through Twitter and scientific meetings, as well as in one-to-one image analysis consultations. Fast4DReg has been successfully utilised by several research groups (Blake et al., 2024; Lopes et al., 2023) and was recently implemented as a napari plugin (https://github.com/Macl-I/napari-fast4dreg). This demonstrates how careful development, thorough documentation and open-source code can support fellow researchers and further expand the implementation of the tool by developers.

AFT (Marcotti et al., 2021) was developed to analyse alignment of fibrillar features in immunofluorescence images of the cytoskeleton and the extracellular matrix, building upon previous implementations (Aratyn-Schaus et al., 2011; Cetera et al., 2014; Fernandes et al., 2020). In particular, it can easily measure fibrillar alignment at different length scales while maintaining computational efficiency, a feature that was missing in other available software tools for similar applications.

AFT takes as input a folder containing images to be analysed. It then outputs an overlay of the alignment vectors over the original input, a heatmap showing the alignment vector field, and a numerical array containing an average alignment score per image. The choice over which output to supply was made thanks to the feedback provided by numerous experimentalists during the software development stage: they suggested that they would prefer a straightforward visual output in order to verify the performance of the analysis, together with a simple exportable numerical output.

Users are required to choose the length scale at which the alignment analysis should be performed. This involves determining two parameters, with clear physical meaning (length and size), in the GUI provided. To aid this process, a parameter search tool was implemented, allowing users to explore the parameter space and identify a length scale where the difference in alignment between two samples is maximised. Similarly to the options for output, this feature was requested by end users as a support tool for selecting sensible parameters for their analysis.

To disseminate knowledge regarding AFT, the tool was presented at various meetings, conferences and open-source software lounges. This allowed us to fine-tune the software and obtain valuable feedback from fellow developers and researchers. Demonstrating its use across input images of different samples acquired with various microscopy modalities and magnifications, and providing the open-software code in both Python and MATLAB languages helped us enlarge our user base. Sample datasets were provided for testing and benchmarking (https://doi.org/10.6084/m9.figshare.15326472.v1), and detailed documentation was prepared both as a methodology paper (Marcotti et al., 2021) and a readme file in the GitHub repository (https://github.com/OakesLab/AFT-Alignment_by_Fourier_Transform). Since publication, AFT has been successfully employed in ∼20 research papers by our group and others for a wide range of applications.

In this Essay, we have proposed a structured process and a short list of recommendations for developers and bioimage analysts who are new to creating image analysis software for biological applications. We hope that separating the process into three main phases and providing a quick checklist will facilitate the development process. Although this list of recommendations is not exhaustive, it is our hope that it will help ensure thoughtful design of software as well as the uptake of the software by a wider community of experimentalists and developers. Additionally, through our own software development experience, we showcase how iterative feedback from experimentalists and careful attention to user-friendliness can lower the threshold for software usage, lead to new software solutions and further bridge the gap between software developers and experimentalists.

The idea for this Essay arose during The Company of Biologists Workshop ‘Effectively Communicating BioimageAnalysis’ (Buxted Park, UK, February 2024). We wish to acknowledge the organisers and the other participants for the insightful discussions. Additionally, we thank Professor Brian Stramer for giving S.M. the freedom to work on this side project and for helpful comments on the draft.