Venus and Mars are Alright Tonight - Or Are They? Why You Should Check Everything Before Launch

By Nigel Cheshire

Last week marked the 57th anniversary of the launch of Mariner 2, the first robotic space probe to successfully perform a fly-by of another planet. Mariner 2 was launched from Cape Canaveral Air Force Station on August 27, 1962, and successfully passed within about 20,000 miles of Venus on December 14 of the same year. (That might not seem that close, until you consider that, even though it’s the closest planet to Earth, Venus is still a good 70 million miles away.) As it passed, Mariner 2 collected various types of data, including temperature (Venus is the hottest planet in the solar system, even though it’s not the closest to the sun) and magnetic field measurements.

If Mariner 2 made the first successful fly-by of another planet, what happened to Mariner 1, you might wonder? It’s a great question, I’m glad you asked. Mariner 1 also launched from Cape Canaveral, just a month earlier than Mariner 2. Minutes after take off, the spacecraft suffered a catastrophic guidance system failure, which led to the craft being destroyed before it went completely out of control and crashed. The cause of the failure appears to have been a humble typo - either a missing hyphen in the code or a missing overbar in the mathematical formulae used to program the thing.

Either way, it was a typo in the code, and the only difference between Mariner 1 and Mariner 2 was the corrected software. The cost of the aborted Mariner 1 mission was $18.5m in 1962, which would equate to more than $150m in today’s money.

The point, of course, is that a small error in software can have expensive (and sometimes life threatening) consequences. There are many examples of expensive software glitches. Knight Capital’s $440m loss in 2012. The launch of the Ariane 5 rocket in 1996. The Boeing Dreamliner integer overflow bug. The list goes on and on.

Most HCL Notes and Domino applications are not what you might call mission critical systems, controlling spacecraft, aircraft or stock trading systems. But errors in your code can still be costly, especially in lost productivity for users. So it’s important to do everything you can to test and assure the quality of your applications before you put them in front of users.

Manual testing is fine, but it’s also a great idea to use tooling where possible to automate as much of the testing load as you can. Which is where tools like Teamstudio Analyzer and Teamstudio Validator can help.

Analyzer comes with a set of predefined filters that will identify potential problems in your code, such as common coding errors, potential performance problems, violations of typical coding standards, potential upgrade incompatibilities, and web or operating system incompatibilities.

Validator is a static code analyzer that also finds potential problems in advance of application deployment. It’ll find things like broken doclinks or URLs, orphaned documents and agent data notes, design note replication or save conflicts, differences between data and design such as inconsistent keyword fields, and missing dependencies such as shared fields or subforms.

While it’s probably true that errors in your code are unlikely to result in a fiery explosion or the loss of millions on the stock market, that doesn’t mean you should ignore software quality. Adding some tooling to your application deployment processes can easily catch some common coding errors before they cause problems for users.

To discuss software quality, or any aspect of HCL Notes and Domino application development and deployment, click below to contact us. We’re always happy to chat!