Does complying with standards automatically mean you have high quality software?
In our experience with the medical device sector, we’ve found that whilst companies are complying with their industry standards (such as ISO 9000 or IEC 62304), many are still concerned about the real quality of their software.
Just because it adheres to the specifications of a certain standard, does that mean the software is also built in a way that is sustainable and future-proofed for the long-term? Will it be able to withstand the creation of new standards in years to come, and is it aligned with your company’s brand vision?
Standards aren’t specific to your business objectives
Whilst standards are sector specific, they are still generic; designed to protect industries and end users from poor practices and cut corners. They apply to all companies with the same product, or in the same sector, but therein lies the problem.
The standards may apply-to-all, but all companies do not have the same goals, objectives and brand visions. Therefore, standards can’t take these into account. One company may want to produce a device as cheaply and quickly as possible to get to market before competitors, while another company may focus on extensive R&D and reliable, cutting-edge interfaces, but they both have to adhere to the same set of standards.
If you want to develop software that can be extended and developed in the future, you’ll be following the same set of guidelines as a company who just wants a one-off and isn’t concerned about scalability.
Therefore, complying with standards certainly shouldn’t be the only consideration when starting out a software project. You also need to consider your business’ goals and needs, because the standards won’t include this for you. When we go through our Illumination process with clients, we make sure to assess the software based on your business’ unique objectives, and translate brand values into practices.
Standards can’t codify quality
Industry standards attempt to systemise practices so that they can be tracked and measured in a quantitative way. But you can’t codify everything, and what you actually want to achieve with your software is quality, and that is very difficult to capture in rigid process documents and tick boxes.
Think of it as a driving test; the instructor has a list of questions and checkboxes to go through, and if the learner does everything correctly (with minimal mistakes), they pass their test. But does that automatically mean they are a good driver?
It means they are an acceptable driver with the necessary skills to be allowed on the road, but this test hasn’t measured the true quality or finesse of their driving, because how can it? It’s just not something a quantitative exam can assess.
It also hasn’t considered the driver’s or future passengers’ (aka end users) goals; do they want to be an extremely safe, or extremely relaxed or quick driver? Do they want to go on to take the Pass Plus test, or even become an ambulance driver?
This is why you should also be looking at your software and development practices in a qualitative way, with real humans and expert consideration rather than automated checkboxes. Our Illumination service does just that, as we have our expert engineers look over the code and processes in the project and assess these with your goals in mind too.
Standards are a minimum threshold
Modern standards are admittedly better than they used to be; most now include a little more than the absolute minimum requirements (like a car MOT, for example!). But they still represent a threshold, or, as we like to think of it, as start line.
Having the goal of your business to simply ‘meet the required standards for your software and processes’, is much like a runner setting their goal to get to the start line of a race. They’ve passed the essential checks to enter, and now they can stand at the start line.
But surely their goal should be to win the race, or at least to excel? Likewise, surely your goal shouldn’t be to just meet the standards and enter the market; it should be to stand out against the competition and see success with a quality product!
Changing your approach from just aiming for compliance to aiming for the best means you’ll be more likely to be building in quality right from the beginning, and adhering to standards will become a secondary goal that happens as a result of that built-in quality.
Ultimately, standards are designed as a guideline used to help your company meet necessary the safety and reliability requirements to go to market in a high-risk industry. But simply complying with them shouldn’t be your end goal, because that of the reasons listed above. There is much more you can do to achieve quality in your software or device, so it shouldn’t stop there!