Wikipedia defines “defensive programming” as

Defensive programming is a form of defensive design intended to develop programs that are capable of detecting potential security abnormalities and make predetermined responses. It ensures the continuing function of a piece of software under unforeseen circumstances. Defensive programming practices are often used where high availability, safety, or security is needed.

Or, if comic style comparisons are what speak to you

Defensive programming? That’s your Jarvis, your AI companion, constantly whispering in your ear, “Sir/Ma’am, potential issue detected.” It’s like you’re in the midst of a high-stakes battle, but instead of lasers and missiles, your weapons are meticulously crafted if-else statements and boundary checks.

Either way, there are three sources of errors to guard against

  1. Logical errors in the code itself
  2. Errors in the input data, especially user supplied input
  3. Errors in the environment

In an interview with NPR Suzanne Dodd, project manager for the Voyager Interstellar mission, explained:

Well, it was a bit unfortunate. We sent a command to update its pointing toward the Earth, and there was an error in that command. And so it’s pointed about two degrees off of the Earth. And from the distance that Voyager 2 is, close to 13 billion miles from us, that essentially points it almost to the orbit of Jupiter.

So it seems like Voyager 2 is faced with a #2 error. It happens. Even to the best of us. I’m sure we have all been there, crashing a production environment here, dropping a live database there. You learn from your mistakes, no shame, no blame, no hurt feelings.

But then for most of us the stakes are not as high as potentially sabotaging a spacecraft that is a ridiculous kilometers away from earth, with no hope of reaching the craft to patch your code if something goes wrong and you loose contact.

But turns out these NASA engineers are some smart cookies! It is rocket science after all, huh? As published by NASA’s Jet Propulsion Laboratory (JPL):

Voyager 2 is programmed to reset its orientation multiple times each year to keep its antenna pointing at Earth; the next reset will occur on Oct. 15, which should enable communication to resume. The mission team expects Voyager 2 to remain on its planned trajectory during the quiet period.

That, my friends is some solid defensive programming right there! If unforeseen circumstances should occur, don’t panic, but rather try to continue as planned if you can. And in the meantime reset any parameter that might stem from bad user input (in this case the antenna orientation) back to sensible defaults.

It might also be worth mentioning that Voyager 2 was launched in August of 1977 - 46 years ago! Plus, it has its conceptual roots in the “Grand Tour” program which was first conceived in the mid 1960s - a decade before!

So, if defensive programming was feasible for engineers half a century ago, I think it is fair to say we should all challenges ourselves a bit more often and take a page out of NASA’s playbook here. After all, Murphy is waiting for all of us…

UPDATE: It turns out, while the self-recovery procedure is a genious solution, it was necessary after all. NASA’s Deep Space Network (DSN) has apparently become strong enough to simply “blast” a signal into the general direction of Voyager 2 and re-establish contact. But … let that not take away from the learnings above!