Life Sciences software is often delivered late, over budget, insufficient or not delivered at all. By following these 5 simple principles you can mitigate the risks and increase the factors for success.
Each software development process attempts to manage the risk of failure in different ways and allows risk in other ways. Choosing a process is a trade-off. As an example, if you spend enough time in the analysis and design phase of project to ensure that you’ll build exactly what the users want and need, you run the risk of spending too much time in that phase. On the opposite side you could build and adapt based on user feedback but it’s possible you’ll spend too much time not delivering the correct amount of business value.
For scientific projects especially, where the data and experimental methods might change as the project proceeds, it usually makes sense to limit up-front requirements and analysis work.
2. Correct Tools
Today’s software engineers have many tools at their disposal. Do a quick search for ‘ToDo app’ and you’ll see this implemented in almost every language; this has become the latest example of the “Hello, World!” And you’ll notice functionally, they all meet the requirements of tracking todo items. So which implementation is right? The correct answer is it depends. There are many non functional requirements that once they are defined can help a software team settle on the correct tool for developing the software.
In the life sciences realm, these kinds of choices are often informed by what libraries and existing software exists. For instance, tools like BioConductor (in R) or MatPlotLib (in Python) could drive the team to use those technologies.
3. Strong Team
Suppose you picked the perfect process and tool that will facilitate easy software development. Are you guaranteed success? No. You still need to execute. This is where the building or choosing the right team comes into play. You hear about it all the time from announcers discussing professional athletes on team sports - they may be amazingly talented but if they can’t work with their teammates then they are effectively useless.
For projects in scientific fields, an important aspect of the team is how the development group interacts with the scientific stakeholders. The team should be set up so that some members can communicate directly and effectively with leadership, and they can disseminate that information to the rest of the team.
4. Understand the Problem
No matter how good the process or how helpful the tools or how strong the team - make sure you are solving the right problems and providing the right business value. The only way to understand the problem is to listen. It’s not just listening to the words but to understanding the motivation for the requests.
Again, being able to do this effectively requires that some members of the team understand the domain. When building a next-generation sequencing analysis pipeline, not everyone on the team needs to be an expert on sequencing technology, but some of the members need that expertise.
Above all - be willing to make a change. If process turns out to not work - choose another one. If the toolset becomes cumbersome don’t be afraid choose another. If the team is under performing and it’s not the process or the tools; rebuild the team. This principle is listed last because it’s a double-edged sword. Inability to change will limit success, but too much change can hurt your chances, too.
In life sciences and biomedical research, the needs of users are always changing due to new lab techniques and analytical methods. Software to support these users will always have to change - finding a way to manage this change without chaos is how everyone will succeed.