Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!hplabs!hpda!hpdslab!hp-ptp!scottg
From: scottg@hp-ptp.HP.COM (Scott_Gulland)
Newsgroups: comp.software-eng
Subject: Re: "software engineers" -- case study (long)
Message-ID: <1670001@hp-ptp.HP.COM>
Date: 5 May 89 02:55:48 GMT
References: <854@odyssey.ATT.COM>
Organization: HP Indus. Appl. Center, Sunnyvale, CA
Lines: 72

>
>Real programmers spend 90% of their time debugging.  Computer science
>curricula ignore debugging, perhaps because it can never be reduced

I beg your pardon!  YOU may spend 90% of your time debugging, but no one
I have known in the last ten years of software development has spent anything
close to 90%.  Most engineers might spend at most 10% of thier time debugging.
The vast majority of thier time is spent, developing internal and external
documentation, design, coding, testing, and a wide variety of release related
activities.  Besides, if you write high quality code in the first place, you
won't end up spending hardly any time at all debugging.  Although a useful
skill, it is definitely not in my top ten list.

> Separating design from implementation is usually a mistake; ask the DoD.)

Don't you mean to ignore implementation during design?  I'll conceed that
in some classes of applications that this might be true, but it is definitely
not true in the general case (no blanket statements).
 
> Other skills I would look for:
> 
> 2. The ability to "port" software.  This is an acid test for distinguishing
>    able programmers from mere C.S. grads.

The problem is there are just not that many people (compared to the industry
as a whole) performing this kind of work.  In the last four years, the
orginizations I have worked for has interviewed well over 500 canidates.
Almost none of these canidates has had any significant porting experience.

> 3. The ability to maintain somebody else's code.  Most C.S. students have
>    no experience in this.

Almost anyone can maintain someone else's code.  The important question is
how long does it take to become fluent in that code.  Especially if it is
poorly documented and/or poorly written.  The amount of experience in this
area can substantially affect their skills.

> 4. The ability to work from specifications.  This includes getting them
>    changed when they need it, and filling gaps by making inquiries or
>    using your own judgment.

In some jobs this might be very important, but not in a lot of cases.  In
many of the jobs I seen and worked on, the development team itself develops
the specs based on customer requirements or feedback (we spend a lot of time
gathering this).  Of course you orgnization may do things quite differently.

> 5. The ability to write software with clean, convenient user interfaces.
>    A good programmer can "see" his software from the user's viewpoint
>    and write for the user's benefit.

Excellent point!  A very rare comodity indeed! 

> 6. The ability to write adequate user documentation.  See 4.

I whole-heartedly agree.

> 7. Experience with a variety of languages, environments, and methods.
>    Not that this experience will necessarily prove useful, but it shows
>    that the programmer is versatile, and probably understands some of
>    the underlying principles of software environments.  By the same token,
>    beware of dogmatism; a programmer with an antipathy to Pascal, COBOL,
>    or VAX/VMS may have a stiff neck.  A programmer who stops learning
>    is technologically obsolete.

AMEN!  You be amazed at the number of people who claim to be engineers
who are unwilling or afraid of learning a new languages, working on a new
OS, etc.  Experience combined with a solid CS background gives an engineer
the confidence to tackle any new language, environment, etc.

Scott G.
scottg@hpiacla
--------------