Re: Standard Library Interest?

["Robert I. Eachus" <rieachus@comcast.net>]

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.