Re: Standard Library Interest?

From: Robert I. Eachus (rieachus_at_comcast.net)
Date: 11/03/03 

Date: Mon, 03 Nov 2003 01:28:30 -0500

Alexandre E. Kopilovitch wrote:

> I wonder, why do you think that mentoring is more important in software
> engineering than in all classical sciences? Or in professions like doctors and
> lawyers? There is enough complexity, and safety requirements are often high
> enough. And no one of them is organized in guilds now. Even those "social"
> sciences that until recently traditionally have competing "schools" (which
> somehow resemble guilds) are gradually leaving that way.

I've seen and participated in attempts to teach software engineering as
an academic discipline. It doesn't work as such. In practice there are
several universities in this area that have good work-study programs,
and when a lucky student does get a good mentor, it works well. But as
far as degrees and curricula are concerned they have little to do with a
student's success or failure in the co-op part of the program.

I've walked both sides of the fence, both teaching at the graduate
level, and mentoring co-op students in undergrad or graduate programs.
(I guess the third side is that my daughter is doing just that at the
University of London.)

I know how to teach Computer Science in a classroom setting. I have no
idea how to teach Software Engineering other than to put someone neck
deep in the middle, then help them to see how to deal with the "Fog of
War" or whatever. Most bright students with a decent mentor/adivsor
"get it," and from then on learn software engineering is just learning
new areas of application.

But everyone here has had to deal with the students who come out of a
CompSci program without that experience. They have been dealing with
toy problems, and programs, for so long that you will never break them
of their anti-software engineering habits.

I could probably sit here and reel off a list of the differences between
a software engineer and a hot-shot programmer, but why bother? Show the
list to one of the hot-shot programmers, and they will tell you why
their way is right, better, or okay since they are "good enough" to get
away with it. The software engineer will say, uh huh, uh huh, uh huh,
oops! you forgot one. Nope, here it is...

In the early days of Ada we used to call that list the "-ilities":
Readability, Maintainability, Relability, Availability, Portability,
Reuseability, Verifyability, etc. The software engineer knows that
designing from the beginning with the "-ilities" makes difficult jobs
easy, and impossible jobs possible. The hot-shot programmer will think
about adding those things later, "If he has to."

Sorry, you touched a hot button. As I say, I know how to create good
software engineers. I don't know how to do it in general in a university
environment. (You can mentor a research assistant, but that is really a
variation on an industrial setting.) I have seen several well-funded and
supported attempts to do it fail. (For example, the Wang Institute.) 

--
 
                                        Robert I. Eachus
100% Ada, no bugs--the only way to create software.