I take issue with both of your conclusions stating that the failures were due to software engineers. In the first case, the English units were certainly given for systems engineering parameters. Do you know how those parameters were generated? It easily could have been a Matlab program created by the trajectory engineers themselves. In the second case, you do a wonderful job of second guessing. If the software engineers have a specification for the sensors that say they will not give a false alarm (I would hope they did not rely on a single sensor, but that is a system issue, not a software issue), they are not going to go around questioning those specifications. In both cases, you seem to think the person who made the mistake should be fired. If everyone who makes mistakes gets fired, I am certain we would have no one left after each person works on a single project. Everyone makes mistakes. One study I have seen says that the general rule is 1 mistake is made for every 10 lines of code written. It is not possible for a single person to remove all of those mistakes prior to integration of that code. That is why there is Software Process Improvement (SPI), Peer Reviews, testing, etc. And that is why the managers should be held more accountable than the engineers (whether Aerospace or Software). The Process was to blame, not the engineer. That is not to say that I disagree with your arguments for better education in software engineering. Unfortunately, software engineering decisions (such as testing decisions) are not always made by software engineers. When the sensor was re-wired, do you think the software engineer who designed the software using the sensor made the decision not to re-test? Not likely. My wife is a scientist (degrees in physics and atmospheric chemistry). She models the upper atmosphere. She does not have any education in software engineering, but that is how she does her work. Many, many professions are like that: the education system teaches the science of the application (aerospace engineering in the case in point), but it does not train people in the correct process to follow to use the science. The colleges and universities say that it is not their job to teach such mundane topics, and they have a good point. It is difficult enough to get a good grasp of all the science, math, logic, critical thinking, etc. that -are- taught. Things like cost and schedule estimation, specific language, and software process can be considered company training issues. It would be interesting to try to come up with a curriculum for an Aerospace Engineer that made a student, after 4 years, ready for any possible job. I focused on the computer aspects, got two undergraduate degrees (Aero Engineer and Computer Engineer) and a Masters degree (in a joint program), and still needed a lot of on-the-job training. So your arguments are not terribly persuasive when you only want to change the Computer Science curriculum. Roger Racine Draper Laboratory At 06:10 PM 12/18/2000 , S. Ron Oliver wrote: >Hi everyone. > >Several weeks ago I indicated I was working on a "flame" r.e. NASA Mars >Projects. I have finally finished it. It became somewhat lengthy. I >generally try to avoid sending such lengthy messages via email, especially >via a list server. > >I have put it on the web at an unpublished URL: > >www.caresscorp.com/Oliver.Academy/scky.sftwr.at.NASA.htm > >I will appreciate any feedback, even if you are in violent disagreement >with anything I have to say. > >sro > >S. Ron Oliver, semi-retired professor of Computer Science and Computer >Engineering. www.csc.calpoly.edu/~sroliver > >Tired of sucky software! ? Check out www.caressCorp.com and follow the >links to software sucks and The Oliver Academy.