How to improve communication between bioinformaticians and engineers in biotech software development

Biotechnological companies are full of amazing specialists who create the future of healthcare. They often have a strong team of bioinformaticians that combine IT, medical, biological, and other specialized know-how. They are responsible for the gathering, analysis, and visualisation of data, as well as prototyping and creating initial versions of the product. That doesn’t necessarily mean they are software engineers and should be tasked with developing a complete, scalable system that’s based on a prototype they created. It’s often best for the “general-purpose” software engineers to take over the project, stabilize it, deploy it and maintain it.

In order to create a quality product, smooth cooperation between these two teams needs to be ensured. And this is equally true whether a biotech company builds its own software development team or it turns to an external software services provider for help.

Defining the roles in biotech software development

First of all, both bioinformaticians and software engineers are crucial to the development process. The former have wide domain knowledge, can rapidly prototype Proofs of Concepts (PoC’s), and don’t have to google up what “reverse complement”, “Hamming distance” or “multiple sequence alignment” are. On the other hand, they might not know much about application architecture, cloud solutions, dev-ops, thread-safety, and good practices in software engineering.

Of course, finding universally skilled specialists is not impossible, however, hiring them may not be affordable, and it’s often better to let people specialize. That’s why you need software engineers – but it would be good if they had some experience in biotech software development. In many cases, keeping your bioinformaticians in-house and outsourcing the software development part of the process is the way to go. Either way, you need to ensure that the two kinds of specialists work together well.

Communicate well to understand each other better

Simply having both the bioinformaticians and the software engineers on board is usually not enough to ensure the desired end result of a stable, maintainable, and scalable product. There are, however, ways to improve the development process in order to minimize the risks.

One of the most impactful factors here is good, flexible communication between the two parts of the team. It allows them to supplement each other’s knowledge more smoothly, especially when the PoC is handed off to the latter team to be turned into MVP and improved upon.

Experienced engineers will rarely have trouble understanding what a piece of code does, but when the domain is as specific as biotech, there are situations in which people without a solid background in the field will struggle to comprehend why it does what it does. Without this understanding, any refactor effort comes with a risk of leaving out some requirements. This, of course, would not be the case if the solution was sufficiently covered with automatic tests or documentation but – in real-world situations – this is rarely an option for at the PoC stage.

Involve the software engineers early on

The communication channels should not be established as late as during the handoff. We know from experience that it’s much better to allow software engineers to participate in the process earlier, at the stage of prototyping (just as it’s important to involve the bioinformaticians during the later software development phase). They don’t need to write the code yet, but they should consult and give feedback about the solution being implemented. Their focus should be on preventing bad architectural decisions before they are made, without delaying the PoC beyond what is acceptable.

This is a tradeoff between having a working PoC and the severity of technical debt that will need to be addressed when refactoring the solution into a production-ready product. The goal should not be to get rid of the technical debt completely but to manage it so that the engineers won’t have to rewrite most of the code basically from scratch. To achieve this, software engineers can be included in some sort of planning or summary meetings. If the prototype is created in the language that the engineering team is comfortable with, they can also participate in code review.

Having worked on a couple of biotech projects ourselves, as Revolve Healthcare, we can clearly see the benefits of such a collaboration model. Before implementing it with one of our clients we witnessed decreased productivity and an increase in technical debt severity, which directly led to increased development costs.

Now, the cooperation runs much smoother:

• The prototyping team consults with experienced engineers on a weekly basis, which allows them to build a much more stable solution.

• Software developers have an easier job with refactors since they can easily consult with the code author.
  

• There’s some more context-switching needed in both teams but overall the technical debt introduced by PoC integration has decreased.
  

Choose and use the technology wisely

Another aspect is tied to the choice of tech stack – ideally, the prototype should be written in a language that both the bioinformaticians and the software engineers know well. Otherwise, a complete rewrite may be unavoidable. The overall architecture of the future system should also be considered – will it be a SaaS, multi-tenant platform? On-premise installation? A cloud-managed serverless solution? Knowing this should make it possible to avoid the time-costly refactors.

To illustrate why this is important, let’s consider two cases, based on real-world scenarios:

• During the prototyping stage, reading the inputs and saving outputs using the filesystem is usually the easiest and the fastest. However, in a production environment it will probably be replaced by database interactions. In this case you could apply the separation of concerns pattern – splitting a crude data access layer – which would make it faster to refactor the code into a scalable and thread-safe solution.
  
  

• If you were to run a Python server that spawns a long-running computation, you wouldn’t want the request handlers to block the threads for a few (or even dozens of) minutes until the child process is complete – this wouldn’t be a scalable solution. Instead you might consider using a job queue to decouple the heavy computations from your server. In order to do that, you would need to change the approach for handling the inputs and outputs of jobs, as opposed to normal per-HTTP request handling.
  

Tooling to the rescue

It’s also beneficial to adopt, early in the process, tools that are normally associated with regular software development – like linting / static code analysis tooling. If set up correctly (with the help of the software team), these shouldn’t slow the prototyping too much, but should, in turn, help avoid some error cases that would be costly to cover later in the development.

This is especially important when adding more modules or functionalities to an existing system that requires maintenance. In this case, the prototyping team should take greater care about adhering to the coding guidelines of the system. Otherwise, the code integration may prove tedious and error-prone, due to the necessary refactor effort.

Is it worth it?

As with any solution, there are downsides to the increased involvement of both teams in the process. The cost of context switching (while not being fully involved in the product) and overall increased involvement in the creation of the PoC makes it more expensive. Despite that, this investment results in better quality code that can be turned into a stable and maintainable solution with less effort later on. In a fast-paced world of biotech (and digital health in general), where you can’t afford to release late – this matters a lot.

This style of cooperation, including a slow shift of responsibility from the prototyping team to the engineering team while maintaining open communication, may not guarantee success, but in our case has proven to be a reliable way of risk mitigation when developing a custom software solution and we highly recommend others to try it as well.

Final thoughts

Being able to communicate well is important throughout the organisation and all its processes, not just the biotech software development ones, and not just between bioinformaticians and engineers. This requires appropriate organisational structure and the use of appropriate tools and frameworks.

We only focus on the aspects important between prototype and scalable software solutions creation here, but if we take just one or a couple of steps back, you’ll see that it’s equally important for Product Owners, scientists, UX/UI designers, and other involved parties (stakeholders) to be included in the process as early as makes sense – not just when they’re absolutely necessary. It pays off to ensure a good flow of information between everyone responsible. It’s also essential that everyone involved speaks the same “language”.

We won’t dwell on this subject here, but we do recommend you read up on Domain Driven Design, Event Storming, and other ways of achieving common understanding and higher efficiency in a project, as well as the company as a whole. We will be writing more about these subjects on our blog in the near future too.