Shuttle clocks

Somebody asked for my opinion about this, and since I was going to write an entry on software quality today anyway, the timing couldn't have been better.

It was on CNN and Slashdot a couple of weeks ago. The space shuttle has an issue where they are concerned about the computer's clock rolling over to January 1st.

http://news.com.com/Computer+glitch+may+limit+next+shuttle+launch/2100-11397_3-6133088.html

To a layperson, it reeks of "Y2K"-ness. You know, the notion that it's stupid and if they can get people into outer space, why can't they make a clock that keeps track of time as well as the $6.99 clock on my nightstand?

To many software engineers (including many in my office), it seems stupid as well. They write code for a living and find it difficult to believe that "NASA could be so stupid".

I disagree with both groups. The reality is that the space shuttle was built of 1970's technology from hundreds of independent contractors. Some have asserted that it was the most complicated machine ever built by man. It has thousands of interdependent systems that have to run in synchronization in order to work properly.

NASA's onboard shuttle computers also run some of the most validated software on Earth (no pun intended).

http://www.fastcompany.com/online/06/writestuff.html

Want to talk about software quality? Try 17 errors found in the last 11 revisions of a 420,000 line codebase. That's phenominal. Average defect rate for commercial software is about 1 per 1000 lines of code (and that's highly conservative). For those unwilling to do the math, that means a commercial application of the same size would have 420 errors (42 times as many as the shuttle software). And then think about how often your PC crashes.

Also bear in mind that this was not an unknown issue. Most bugs are found as a result of running into them. In this case, it has been a known recognized issue for years. Given the fact that the issue was well understood and there are always bigger fish to fry, NASA made a conscience decision to not run the risk of introducing more bugs by making a change.

So, I guess the answer is "no", I can't fault NASA too much for choosing to not fix a known issue that has zero probability of occuring in normal operation (meaning not flying the shuttle over New Years), when there are plenty of other issues to worry about -- like faulty O-rings and insulating foam coming off the fuel tank at supersonic speeds.

What code DOESN'T do in real life (that it does in the movies)

For those of you friends and family not in computers, here's a very funny summary of the differences between real programming and how it is depicted in the movies

What code DOESN'T do in real life (that it does in the movies)

Quote:

I understand that Hollywood needs to dress things up to make them more entertaining, but in the case of programmers, code, and hackers they've done more than dress things up - they've morphed a little stuffed teddy bear into a cybernetic polar bear covered in christmas lights and phosphorescent hieroglyphics with a fog machine pumping rainbow smoke out of his ass.

It's a good read.

Lasalle library

Spending Saturday afternoon in the Lasalle library with Vikki, doing some investigation into the Mysql schema used in MythTV. The program guide has gotten faster since I deregistered the channels I do not receive, but it should still be much quicker. On my Tivo doing a pagedown in the program guide is instantanous, and that thing only had a 60 MHz PowerPC CPU. My MythTV box has a 2.4 GHz Pentium 4, suggesting that there is significant inefficiency in the software doing database access.

Admittedly a bit hard to profile the performance of my living room television from Pennsylvania. Ah, the wonder that is SSH....

After work last night, went out for Thai food with Shamoun, Naoum, and Joe. The company and food were good, but I was already exhausted and probably should have just gone home early and slept. Such is life.

Tired

Think I might be coming down with a cold.

Worked at the office until a little after midnight. Ran into some bugs that took longer to fix than I thought they would. Then ended up doing some cleanup work while the code was still fresh in my mind.

Going to Philly tomorrow night which should be fun.

Need to finish painting the kitchen. Just haven't had the energy at all this week when I got home after work. It will be nice to not have the refrigerator in the middle of the kitchen (pulled away from the wall), since I walked right into it at 3am last night. Ouch.

Federal Panel Rebuffs Guidelines That Insist on a Paper Trail

Federal Panel Rebuffs Guidelines That Insist on a Paper Trail

http://www.washingtonpost.com/wp-dyn/content/article/2006/12/04/AR2006120401290.html

Why on Earth would the federal government follow recommendations from the National Institute of Standards and Technology? It's only what they specialize in -- standards and technology...

Devin goes clubbing

Yes, you heard it right. Went clubbing with Vikki and Ali last night in central Philly. They had a friend who was celebrating her birthday.

I don't dance.

I don't drink.

Anything over 90 decibels and I can't make out speech from background.

It was fun nonetheless to get out and do something different.

Started looking into the source code to MythTV. Established contact with the author of KnoppMyth, and am looking at improvements I can make the installation process smoother.

Saturday

In Philly with Vikki, spending the afternoon at the coffee house working (she's studying too).

NIST has come out against electronic voting without paper trails. About friggen time:

http://www.washingtonpost.com/wp-dyn/content/article/2006/11/30/AR2006113001637.html
http://vote.nist.gov/DraftWhitePaperOnSIinVVSG2007-20061120.pdf

Joe sent me this article yesterday on the origins of cleverly optimized inverse square root function (used in Quake 3).

http://www.beyond3d.com/articles/fastinvsqrt/