Building a mission critical product like a diagnostic, life science or cell therapy instrument requires robust software that works seamlessly and performs its intended function reliably, every time, without hiccups.
One way to achieve that would be to gold-plate the quality, gold-plate the testing, gold-plate everything. But whether you’re a start-up or a multi-national company eagerly trying to get your product in the hands of customers and key opinion leaders (KOLs) as early as possible, the commercial reality is that your budget is limited and so is your time. So, gold-plating anything is not an option.
PI understands this and has not only built a strong team of software engineers, but has also developed processes and a risk-based approach to software development that our clients are consistently calling out as best-in-class.
In this article I want to share some of the key strategies which we have refined to deliver our clients the right product with bullet-proof software and no long tail to their development projects.
1. Utilize a cross-functional team
PI’s approach of adopting a cross-functional team for our product development ensures the software engineers and testers understand the hardware, science and the workflow, which is especially useful when designing regulated products.
Good firmware requires strong collaboration with electronics engineers and systems architects. Therefore, the software team is integrated into the broader ‘systems’ approach ensuring our developers and testers know everything they need to about the hardware their software is running on.
A key goal for our cross-functional teams is to design out complexity from the system. For example, you don’t want to design an electronics system that inadvertently creates additional burden on the code to support unnecessarily complex protocols or avoidable systems edge cases. What good looks like is your firmware engineers sitting with your electronics engineers, working together to design the system and selecting things like peripherals together. Another example is simplifying the instrument workflow scheduling. For electromechanical instruments with sophisticated robots and protocols, scheduling can be incredibly complex. However, the right collaboration of skills will actually design out complex scheduling through smart choices and applying a deep understanding of the hardware, software and chemistry. In some siloed product development companies, it is common to see them design an overly complicated hardware system which they hand off to a software team with the hope that they can fix all their issues through coding. PI avoids these costly design choices by breaking down the barriers between our teams.
2. Design an extensible architecture
Everybody wants to have ‘well architected software’. But what does that really mean? PI approaches architecture from two perspectives. The first is about good, overall software architecture that will provide reliable, scalable software. For example, does the architecture support multiple teams working on different aspects of the software at the same time while maintaining a strong, reliable code base? Good architecture also enables changes in features or functionality without having to change underlying architecture. This requires building quality and flexibility into the design from day one so that you have predictability and on-time delivery. You can roll the dice and just try and build it and test at the end, but then you are almost guaranteed to have a long, costly tail to your project because you have inadvertently built a lot of unknowns into your product.
The second perspective considers the regulated nature of the product. Does the architecture meet the safety class requirements for future validation? What are the extensible choices we should make from a regulatory perspective? For example, when dealing with a Class B safety system, there are specific demands on how the software is architected. You have to isolate systems and provide high levels of traceability. From the very start we are designing software that is going to fit into the system requirements and provide this traceability.
Good architecture from both perspectives is key. If you don’t cut the architecture right, this bleeds out into your testing, verification, risks and costs. It can also increase the severity of defects in the system.
3. Use Accelerators to save time, save money and de-risk
PI leverages a suite of pre-built modules to reduce the time and cost of the software development while having the added benefit of ensuring reliable code that has been pre-tested. By utilizing these Accelerators, as much as 20% to 80% of the code doesn’t have to be written from scratch, resulting in a significant time and cost benefit for our clients. In a recent project developing a complex diagnostic instrument 45% of the electronics code and 50% of the software code was provided through pre-built Accelerators dramatically reducing the customer development. This allowed the team to focus on project-specific requirements that were novel and unique to the product. These Accelerators provide routine software functions that every product requires, for example, driving hardware, enabling connectivity and supporting automated testing. Accelerators help all product development, but they can be incredibly beneficial to start-ups who are often cash strapped, haven’t proved out their tech, aren’t sure if they are even going to make it to market and so they are having to take calculated risks with the amount of quality they build into their product. Accelerators provide quality, strip months out of the schedule but don’t compromise the competitive nature of their core tech. It’s a free hit in what is a complex game.
4. Prioritize through process
A lot of people developing products have had bad experiences receiving fragile software, or software that is not fit for purpose. PI has a range of mature processes that allow us to work with clients and ensure they get the right product every time. Our processes, like story mapping and user journey mapping, actively engage our clients, ensuring they are in the driver’s seat of decisions that ultimately prioritize their most important needs and consider their individual risk appetite. These mapping workshops help define the Minimal Viable Product (MVP), which is a fully compliant, safe, reliable product, but only includes an initial, prioritized feature set.
Product features that seem very important at the start of the project, often make way for a greater focus on things like enabling core technology. Those original functions and features are not lost forever, but they may not be needed for a couple of years, or in subsequent versions of the product. Deferring non-core functionality until later can save our clients millions of dollars and reduce their time to market. Our story mapping and user journey mapping processes lead towards a shared understanding of the key product priorities across the entire team, resulting in a simpler, more robust product.
5. Test continuously
Testing is a key element to building robust software into your product. When and how you test impacts the quality of your code.
PI’s strategy is to have testers on board throughout the project, continually testing. By conducting in-sprint testing as part of our agile approach, we find the defects upfront. Our whole mechanism is geared towards finding any issues as early as possible because bugs that are caught early are far cheaper to fix. This is especially true with regulated systems. If you only catch problems in the verification cycles or validation at the end, the cost can be exponentially higher, and the timeline can blow out.
We always separate the testing role from the development role to ensure independence. It’s surprising how often companies will have the same people developing the code and developing the tests. Experience has also taught us that you want to strike a balance between automated and manual testing. Automated testing is a powerful mechanism to continuously check the quality of your code. However, there are certain situations where manual testing may be appropriate. PI applies both approaches across unit and integration testing, including cross-functional integration testing, as part of our de-risking process.
Ultimately, our testers are a key ingredient to building robust software. And while they are independent to our developers, they are still an integrated part of our overall systems approach.
6. Stay aligned through close client collaboration
Often trusted to develop incredibly complex products, PI has not only built processes but also refined a culture of open communication that ensures a highly collaborative way of working with our clients.
We encourage our clients to empower a Product Owner who plays a key role in the project and is involved in regular, key touch points, such as stand ups and planning sessions. They are crucial to the development of the product. We recognise that the best way to keep our client in control of the overall direction and the scope of the deliverables is to have those integrated touch points throughout the journey.
We do simple things like sharing a unified backlog through tools such as Jira, which ensures we are building a robust product that is fit for purpose for our client’s needs.
This high-engagement model keeps us aligned, and our clients stay involved in incremental changes to scope and any risk management discussions, which all impact the robustness of the final solution.
7. Select best-in-class tools
PI has a quality process that is compliant with IEC62304 and a range of tools and infrastructure to support software development, hardware development and hence product development. We are ready to hit the ground running in all cases when a client comes to us. While selecting the right tool is important, it is more about how you use the tool and integrate it into the overall process that really counts.
PI uses best-in-class tools like Jira, GitLab and Codebeamer to support key tasks like client engagement, scope management, risk management, safety and traceability. They also support technical processes like code reviews, continuous integration and deployment, unit integration and critical architecture reviews.
Due to the regulated nature of the products we build, we have also developed tools and processes that are aligned with IEC 81001-5-1, a healthcare standard that specifically addresses cybersecurity challenges in medical software development and is recognized by the FDA as a consensus standard.
Combining all these tools with deep domain knowledge all leads to better software outcomes for our clients.
Closing Comments
When highly innovative products make it to market and deliver outstanding results, it’s a clear indication that under the hood well-architected, robust software has been built into the product.
PI has fed decades of experience across a huge range of products into our continuous learning process to develop best-in-class software and firmware development practices. By combining these practices with ready to go Accelerators you can deliver both robustness and flexibility to a complex product development process.
Our methodology allows our clients to decide what is in and out of scope and what risks they are prepared to accept. And by using PI’s cross-functional teams it ensures we drive out complexity from the design where we can, and don’t over-engineer or under-engineer the software.
The combination of all these strategies enables us to deliver exactly what our clients need – the right product with bullet-proof software.
Authors
The article was authored with contributions from PI’s Software Leadership Team including Annika Busch, Drew Foster, Philip Peitsch and Wayne Cheetham.
