LifeFormulae Blog » Posts for tag 'errors'

Computer Science Wild No comments yet

(I’m delaying the “horror stories” until next week, because I want to fully document them all.)

 

I ran across the phrase “computer science wild” at a recent conference.   I’ve got my own thought, especially since  the top 25 coding errors was released yesterday.  The link to the article  is - http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9125678&source=NLT_SIT&nlid=91.

 

I think any programmer should have the opportunity to write software that might kill someone, blow up an extremely expensive piece of equipment, or cause a waste of thousands of dollars because the system is down.  Maybe then they would think, write better code, and debug the software thoroughly before they released it into the wild.

 

The Ariadne V rocket blew up on take-off because the software didn’t contain an exception handler for buffer overflow!   (This translates to something like an array overflow. An overflow would trigger a programming mechanism that would write out the buffer contents and clear it.  The usual device is to transfer data capture to another buffer while the full buffer is written to i/o.)

 

The excuse for the disaster was that the specifications didn’t spell out the need for that programming mechanism.   An exception handler is a very basic mechanism for catching and correcting errors.  There is no excuse for this oversight.

 

One major project I worked on was acoustical (noise) testing of aircraft engines.  Our crew would go to some really great places like Roswell, NM, Moses Lake, WA, or Uvalde, TX.  We would record and analyze the noise of the engines as the aircraft flew over at different altitudes with variable loads in various approach patterns.

 

There were several pieces of software that had to work in tandem.  The airborne system, the ground-based weather station,  the meteorological (met) plane, the accoustic data analyzer, and the analysis station all had to work together to get the required results. 

 

There was no room for error.  Measuresments had to be exact, even out to 16 places after the decimal point. 

 

Modeling techniques, programming languages and IDEs (Interactive Development Environments) have become very sophisticated and complex.  A programmer today can “gee whiz” just about anything.

“Because we can” has become the norm.

 

This is great, but I’ve run into lab techs, etc. who were just this side of computer illiterate.  Like my dad, they adhere to a limited number of computer applications, accessed by a few key strokes or mouse clicks they have memorized.

 

And don’t think that engineers are immune.  They had to be drawn “screaming and kicking” away from their sliderules.

 

I’m for simple to start.  You can always add more “bells and whistles” as the system (and its users) matures.

 

 

 

Top of page / Subscribe to new Entries (RSS)