On 7/27/06, Jason Stephenson <[EMAIL PROTECTED]> wrote:
Code Review (auditing?) would be a good class subject.
I got my training as a Mechanical Engineer ('88). We really didn't study real world stuff. We worked on theoretical models. Think physics type stuff, but much more in depth - no frictionless surfaces :-)
We had a few project classes an a lab that dealt with more real world stuff but most of those projects were electives.
One thing that appeared in many equations was a factor of safety. A NASA program would wittle that to the bone (<2) and a bridge would be closer to 3. Redundencies were usually built in. How much software crashes instead of failing gracefully?
And of course, it's easy to analyze the design and redo it with a different tact (what if I used 1040 steel instead of 1060? Change the gear driven stuff to chain or belt driven?)
I don't think that's easy to do in software. If it was, you'd see more things like emacs vs xemacs which (from what I understand) are different in thier data structures and programming style.
Do you know why? Most programmers don't really get to see that much
source code. It's true. In the commercial realm of closed source
software most programmers only get to see the code of the project(s) to
which they are assigned. They never get to see much code that's better
or worse than what they are used to seeing.
The same is true in most university CS programs. Students are not
exposed to all that much code. It's mostly theory and mathematics and
then applying that theory and mathematics in code.
Code Review (auditing?) would be a good class subject.
This is very far from what most architects or engineers do in their
educations or their careers. They study other's designs and
implementations. They appreciate one another's work as art. Closed
I got my training as a Mechanical Engineer ('88). We really didn't study real world stuff. We worked on theoretical models. Think physics type stuff, but much more in depth - no frictionless surfaces :-)
We had a few project classes an a lab that dealt with more real world stuff but most of those projects were electives.
One thing that appeared in many equations was a factor of safety. A NASA program would wittle that to the bone (<2) and a bridge would be closer to 3. Redundencies were usually built in. How much software crashes instead of failing gracefully?
And of course, it's easy to analyze the design and redo it with a different tact (what if I used 1040 steel instead of 1060? Change the gear driven stuff to chain or belt driven?)
I don't think that's easy to do in software. If it was, you'd see more things like emacs vs xemacs which (from what I understand) are different in thier data structures and programming style.
source programmers cannot do this, while open source programmers have
the opportunity. (However, I doubt very many of them do this.)
Additionally, software is in its infancy. I imagine that the first few
thousand bridges that were built were pretty dodgy things. They were
probably very likely to collapse under you. It took mankind a long time
to figure all this out. (They still don't always do it right as the big
dig mess is proving.) Software is a bit more complicated on the inside
than making a bridge, too.
Writing software is like writing fiction or nonfiction in the sense that
the only way to really get better is to do it. You read a lot and you
write a lot.--It helps to eat your own dog food, too.
_______________________________________________
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
