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 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
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.
At 06:10 PM 12/18/2000 , S. Ron Oliver wrote:
>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:
>I will appreciate any feedback, even if you are in violent disagreement
>with anything I have to say.
>S. Ron Oliver, semi-retired professor of Computer Science and Computer
>Tired of sucky software! ? Check out www.caressCorp.com and follow the
>links to software sucks and The Oliver Academy.