There is a hidden cost in developing and supporting automated calibration procedures, that is the cost of supporting and updating the software after the initial development cost. The industry sets an average metric of 80%. When I first saw this number I thought NO WAY! I thought like everybody else thinks, my software is better than that. There is no way it cost 80% more!
I am here to tell you, those hidden costs are no joke. Even the best software developers and projects have those hidden support costs. There is no stopping them, there are too many unknowns.
Last month we got hit with one of these hidden unknowns that breaks software. Microsoft updated the TSL v1 on their Azure service. This broke a tool we wrote many years ago called MetMigrate, a tool that moves data from MET/CAL® to another database. With the recent changes to web security, this TSL v1 update broke the MetMigrate application and it could no longer push data with a REST service call.
And the cost is not just the hours it takes to update the application to resolve the issue. For one, there is an upset customer with a work stoppage, plus the time it takes to create and implement a work-around until the software is fixed and tested. Also, there may be some errors that need to be corrected because of the manual work-around.
On the development side, this project’s source code was four years old. Like many projects, the developers have moved on to other projects and may not have the time to fix this issue on the customer’s timeline. This adds the cost of bringing in another developer up to speed on how the code is structured.
Sometimes we get lucky and fix it in one shot. But most of the time, it is several iterations before the updated software is 100% with all the changes. With each iteration comes testing costs, inching ever closer to that 80% cost and sometimes going over it.
I like to use Scotty from Star Trek as an example. He always multiplied the time it took to do something by seven. Not to make himself out to be the hero, but I think in the back of his mind nothing goes as planned.
Something I have learned over the years: take the estimated time, then multiply it by some factor, because no battle plan survives first contact. Now I think about the 80%, and the 80% of the 80%—yes, when you fix something there is a 64% hidden cost to that work as well.
Even in simple projects like the Power Supply calibration, these costs always seem to be there. After the initial development and testing of the software around the Fluke 8588A and EL34xxxA electronic load, we needed to add the N3300A loads. This required some refactoring of the code to support using multiple electronics loads in series or parallel. Those changes required additional testing to ensure we didn’t break the EL34xxxA code (the 80% of the 80% hidden cost).
Then we updated the code to support the HP/Agilent/Keysight 3458A. This requires some additional refactoring of the code to support current shunts because the 3458A’s maximum current is limited to 1 Amp. And like before, we needed to test these updates didn’t break the 8588A code. Plus, we wanted to allow the 8588A to use current shunts as well, so more testing and code updates.
Then as we are testing one of the newest power supplies, the Keysight E362xxA Series, we discover they have added multiple line and load regulation test points. So now we have to update the test process to support multiple test points for each test group, adding even more cost to that 80% estimate.
Most software has a five year life. Most software companies charge 20% for their support and maintenance (5 * 20%)—pretty easy to see where that number comes from! But metrology software and test equipment often have a life way longer than five years. So Scotty may not be too far off with his 7x the initial estimate.
