I recently read The Martian by Andy Weir. Since this information comes out on the first page of the book, I don’t think I’m spoiling too much to say that it is the story of an astronaut, Mark Watney, who is lost in a space storm on a mission to Mars. He is presumed dead by his crewmates and abandoned on the planet. Of course he is not dead and he has to use training, skill, ingenuity, and luck to survive long enough to be rescued. Several times throughout the adventure, he has to connect life supporting utilities, tanks, airlocks, and vehicles together using the connecting valves supplied on each component. Watney says, “I’ve said this many times before, but: Hurray for standardized valve systems!” This is obviously a work of fiction, but what would have happened if he had tried to attach a holding tank to the ascent vehicle but the valves had changed between versions?

Software customers should be able to have the same expectation as Mark Watney that the valves don’t change during the mission. In the case of software, we aren’t talking about physical valves. Rather we are talking about software interfaces and API method signatures. In a real sense, the consistency of these software signatures are as mission critical as the standardized valve connections were for the astronaut in The Martian. Changing the method signatures, at the very least, requires that the users of the software have to rebuild their applications. Often times such changes require software users to have to requalify their entire tool. This places undue burden on the users of the software. Software users should be able to reasonably expect that the interfaces and API remain constant through the life of the mission (i.e. within the version of the software including minor releases and patches). A side note on this topic: If Cimetrix product management determines that a piece of software has a bug or does not conform to the SEMI standards on which our products are based, changes will be made to correct the problem. Similarly, if NASA determined that one of their connectors did not conform to the spec, they would immediately resolve the issue for the item that was out of spec.

The Cimetrix release versioning process (see our January 14, 2016 blog) allows Cimetrix personnel and Cimetrix software users to be aware of what backward compatibility guarantees are made for a specific version of Cimetrix software.

We would like our software users to be able to say, “Hurray for compatible software versions!”♦