by Michael Schwartz
Over the past 30 years of my software and automation career, I have migrated to a modular approach to software design. I come from an Object Oriented Programming (OOP) background and I am a firmly in the camp of agile/lean software development. That means I have an inclination to dislike monolithic software designs. It is not just me; the other software engineers I know–people who do nothing but write code all day–they also prefer a flexible, reusable and modular design. So I was surprised to discover the next release of MET/CAL® will only support PXEs.
This got me to thinking, is metrology better off with larger monolithic calibration procedures or with smaller, well architected and interchangeable parts? At first glance, one would think it is easier to QA procedures in one single pass: run it start to finish, QA the results, and then put your quality stamp on the procedure.
The problem with a monolithic automation is the long-term costs! First of all, there is the cost of creating the QA process and documentation! The more you have to check, the longer the QA process needs to be and the easier it is to miss something or skip a step.
Now you have to multiply the QA costs every time you make a change to the procedure. It could be a simple change to the pass fail limits on a test point or something as complex like a complete change of the standards being used and uncertainty calculations. If your process is a full QA check with every change, and there are no shortcuts allowed, each change will be a timely process costing time and money.
There is a much better way! It’s called modular programming, which is a software design technique that emphasizes breaking the program up into independent, interchangeable modules. Each module can then be tested, validated, and QA-ed independently.
The total QA process times between the two would be equivalent the first time. However, with modular software design comes a modular QA system; just like how the modular software is compiled into a single application, the sum of the QA process is the sum of the QA modules.
This saves time and money in both the development and the QA side! Modular object oriented programming is a time tested, better way to develop and support software. Now QAs can be done with a unit testing approach where each component of the software can be individually and thoroughly tested. Much of these QA processes can be run automatically using unit testing tools. It is important to note, just about all modern software development tools today have a unit testing package and revision control tools where they can be configured in such a way that the QA processes are run before any changes are checked in.
The bigger question seems to be “Why do people trust a monolithic QA procedure more than a more modular one?” My guess is because people poorly execute their monolithic QA processes. Because people short cut the larger QA thinking or underestimate all the ramifications of a simple change, errors appear in production. I have seen this first hand, back in my early programming days. I had one developer on my team, my boss, who would always be coming up with a better way to do something. So he would code it and check it in. Often, those better ways were not better. They seemed to work better with that UUT and that set of standards, but all too often they broke more things than they fixed.
When the UUT and standard code is so tightly integrated into one monolithic program, it is very difficult to isolate and resolve the problems. And if you do manage to find and fix a problem with the standard, now you have several UUT procedures with which you have to find and fix the same problem… and then QA!
Modular programming does require a little more forethought! When you are working on the UUT code, you are not thinking about the standards or any idiosyncrasies related to the standards that will be used. Your focus has to be solely on the UUT code, test points, test limits, and setting. And when you are working on standard code, drivers, and uncertainties, you shouldn’t be thinking of a specific UUT’s idiosyncrasies.
When it comes to testing and QA-ing the UUT code module with multiple standards, your end result is more reliability and repeatability in the code. You can even QA the test limits and verify what test points will be executed on a specific make model option configuration. The same is true for the standards and drivers; the more UUTs using them, the better the reliability of that driver’s operations.
So, I am always going to be a modular code kind of guy, and so will my company. The challenge is going to be getting the auditors and QA guys of the world to see they actually have less work and a better quality system with modular software and a modular QA system.
