JTSR

Slashdot ran a story this morning about the state of NASAs computers in the shuttle, the idea that you will never see a shuttle in space over the new year.

It is interesting as it does demonstrate that a simple new requirement (or I suppose in this case a requirement that was possibly missed out during the design) can turn into quite a lengthy task when it comes to Software Testing. In this case there might be minimal or no development work required, but a lot of investigation, simulations and code reviews in order to determine the risk.  Add to this and the idea that I’m sure computer systems on the shuttle are duplicated a number of times and have independent software systems designed, written, and tested by independent teams - so add this into the risk equation.

It should all in theory work fine, or at least the internals should as they would no-doubt all be working on a number of ticks or a number of seconds since a certain time, with any luck all database records would be using the same concept.  Computers have no concept of dates or timezones, they just know it has been x number of ticks since a key time in history. Â But it is when they have to convert their handy time tracking format into something that humans can understand, or they need to convert an input from a human into something that makes more sense to them, that they might come a bit unstuck. Â It is then up to the mercy of the programmer a lot of the time to make sure they sanitise the inputs and the outputs, and it is when something a bit strange it doesn’t just give up.

For NASA, think about the “customer impact” against the “business sense”.  There may, or may not, be a bug or bugs when the year wraps over to a new one, it occurs only once a year.  The shuttle have been flying since the mid to late 1970s and during this time they have not had to have a shuttle in space over the new year.  Maybe because of this worry, but all the same it has not greatly affected space flight.  So, the business sense of investigating this possible problem is quite low, it has not been a critical problem before.  Added to this all the hundreds of programmers and ex-programmers that have worked on the software for NASA in the past, working on source code spanning nearly 30 years in no doubt a mixture of assember, C, you never know if you might find a bit of Java in there too!  Huge amount of effort then for a low business sense and low customer impact possible problem.

A full risk analysis would surely show little gain for high effort = leave it alone.