Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!bu-cs!bloom-beacon!apple!shebs
From: shebs@Apple.COM (Stanley Todd Shebs)
Newsgroups: comp.software-eng
Subject: Re: software engineers
Message-ID: <1764@internal.Apple.COM>
Date: 10 May 89 17:39:53 GMT
References: <4951@pt.cs.cmu.edu> <1736@internal.Apple.COM> <493@bnr-fos.UUCP>
Organization: Apple Computer Inc, Cupertino, CA
Lines: 57

In article <493@bnr-fos.UUCP> schow%BNR.CA.bitnet@relay.cs.net (Stanley Chow) writes:

>I would consider 50K lines to be a (very) small part of a big software systen
>or project. (No smiley). If one person cannot totally comprehand a small program
>like that, either the person or the method ought to be examined carefully.

50K lines *per person* is an approximation I picked based on observations
in several different industries over the past few years.  I'm assuming
relatively sparse commentary, as seems to be the norm (sigh) - heavily
commented code might be 2-3 times longer.  Note also, "total comprehension"
is pretty extreme.  It means for instance that somebody could pick any single
line and you would be able to justify its existence, explain why alternatives
were not used, mention how it relates to the specification, and comment on
the consequences of changing it in various ways.  Total comprehension is
actually somewhat rare, since it is possible to write and even debug software
without understanding it completely.

Incidentally, the "50K lines == small" statement is a familiar one, but I've
not seen any reliable and up-to-date statistics on program sizes.  Is there
a believable chart anywhere of sizes, numbers, and the numbers of people
involved?

>In big systems, even in small 50KLOC programs, it is important to partition the
>program into understandable chunks. S/W people call this module interface. The
>civil/mechanical engineers call this "specification".

Only amateur programmers and researchers work without specifications these
days.  The issues revolve around how formal the specifications can be.
Informal specifications seem to cause as much difficulty as they resolve,
while formal specifications are fantastically hard to get right.

>May be the answer is a mandotary course in "standard writing" for all
>software enginees.

Undergraduate software engineering classes feature the writing of interface
specs, but the environment is too artificial to get students to feel a
realistic level of pain at having to conform to a bad specification.
Classes can't always substitute for experience...

>[...] I like
>to think that some, if not most, software projects are run better than you 
>make it out to be. If the situation is indeed as bleak as you say, then I 
>would worry about the future of S/W, especially in the USA or North America.

I always have an eye out for the well-run software project, but a little
digging generally reveals that much of the proper methodology is window
dressing, concealing the programmers-who-despise-software-engineers who are
cranking out miles of code.  I've been observing this ever since my first
software job, which involved writing documentation for an entirely
comment-free Fortran program, to make it appear as if it had been constructed
according to the DoD's standards for delivered software...

							stan shebs
							shebs@apple.com

(What about Apple?  Well, I'll have to dig around and get back to y'all on
Apple's software engineering standards)