[comp.software-eng] Engineering Was: Texts...

rsd@sei.cmu.edu (Richard S D'Ippolito) (04/07/89)

In article <601@mitisft.Convergent.COM> G.M. Harding writes:

>     More seriously, your main point is well taken. The best programmers
>I know are well-rounded human beings. I've always taken a certain amount
>of pride in the fact that I don't have a BS or MS; rather, I have a BA
>(history). One of the best software engineers I ever knew had a BA and
>an MA (music).

That reminds me of a visit the poet Robert Frost paid to MIT (I think) many,
many years ago.  He was being given the grand tour of the engineering school
by the dean, who kept emphasizing all of the non-engineering courses the
student had to take -- philosophy, literature, etc., commenting that "We
produce well-rounded engineers here."  Frost sniffed and replied, "What are
you going to do with them, roll them down a hill?"

I would humbly suggest also that your pride is seriously misplaced.


>     We often miss the point of what an engineer really is. An engineer,
>in any discipline, is one whose job consists of translating theory into
>reality. Hence, first and foremost, engineers are people well-grounded
>in reality. 

This is backwards and a bit too loose.  Engineers turn science into useful
products, so the grounding in the science has to come first.


>In the software engineering discipline, that implies a deep,
>almost intuitive understanding of, or "feel" for, how computing machines
>work.

Hardly -- there's no reason to get mystical about it.  It's this
much-venerated "intuition" that's keeping software development in the craft
stage.


>     Second only to being well-grounded in reality, however, software
>engineers ought to understand basic theories. This includes algorithm
>theory, of course, but in a broader sense it encompasses all branches
>of human knowledge: Science, mathematics, commerce, even the much-
>maligned liberal arts.

Nonsense.  Software engineers, like all other engineers, need to understand
the underlying science -- in this case, computer science -- which may or may
not include algorithm "theory" (Do all mechanical engineers need to be
experts on making steel?) and be taught the engineering methods used to
apply their science.


>     This explains my conviction of long standing that C is the ideal
>engineering language. Most other languages place their emphasis on the
>latest algorithmic nicety to come out of academia. 

I hope you mean programming language.  I know a lot of good engineers who
have never spoken or written "C".  The second statement is unsupportable.
Perhaps you are objecting to languages designed to incorporate features that
make them more responsive to (software) engineering needs.  If so, I think
that you fail to see the language as a means, and see it as an end or a
purely acedemic exercise.


>That's putting the
>cart before the horse. We are engineers, not academicians or theore-
>ticians. Our job is to MAKE IT WORK, and that means that our first
>emphasis must be on the machines that will do the work.

Right, we will be engineers when we make it work in the same sense that
cars, bridges, chemical plants, computer hardware, and steel mills are made
to work. Do you think that those engineers make their products by intuitive
feel?


>     Since, however, we must translate theories from all walks of life
>into computing models, it behooves us to understand theories of many
>different types, if only so that we can tell our clients when they're
>dreaming.

I would suggest that we understand modeling, first.  We will then see that
it is not theories that are translated into models.


Rich
-- 
---------------------------------------------------------------------------
Ideas have consequences.                                    RSD@sei.cmu.edu
Richard Weaver
---------------------------------------------------------------------------