HDTenEightyP/NetNews huggingface dataset:
From: feathers@serss0 (Michael Feathers)
Subject: Re: Putting Engineering into Software Engineering
Organization: Florida International University, Miami
Date: Sat, 19 Dec 1992 03:09:05 GMT

In article <1992Nov28.032512.26295@mole-end.matawan.nj.us> mat@mole-end.matawan.nj.us writes:
>In article <rzeplins.722559935@sfu.ca>, rzeplins@fraser.sfu.ca (George Zygmunt Rzeplinski) writes:
>> What is needed to call Software Engineering "engineering"?
>
>(This discussion, again?)
>
>Models that assist understanding, communication and recording of analysis
>and design, and that are universally applicable and universally indispensible.
>
>In electrical engineering, there are circuit theory, transmission line
>theory, and electromagnetic field theory.
>
>In mechanics, there are Newton's Laws and the various laws of elastic
>behavior, combined with vector and tensor analysis.
>
>In thermodynamics, there are the laws of thermodynamics and various
>variables and equations of state, as well as the statistics of statistical
>thermodynamics.
>
>In chemistry, there are reaction equations, reaction rates, and lots of
>things I never understood.
>
>All of these illustrate what software is missing.
>-- 
> (This man's opinions are his own.)
> From mole-end				Mark Terribile
>
> mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ



Gee..   what about logic, computability theory, formal languages, cohesion,
coupling, and knowledge representation?

I'd consider any of those as universally applicable in software engineering.

Newsgroups: comp.software-eng,comp.lang.c
From: tomj@monster.apd.saic.com (Tom Johnson)
Subject: Write Only Commentary (Was Re: C Code Layout)
Organization: SAIC, Reston, VA
Distribution: comp
Date: Fri, 11 Dec 1992 19:00:09 GMT

>>>>3. What formats are most effective for comment headers of
>>>>functions and what kind of information is appropriate for these.
>>>
>
>>HISTORY
>>       Author     Date          Description
>>       -----      ----          -----------
>>        pam     12/07/91        initial spec
>>        moh     12/18/91        made arg1 optional
>>        xac     06/22/92        correct something TR 92w1234
>
>I've always wondered about this sort of thing in a source file.
>Is this sort of information considered useful?  I know several 
>programmers who refer to this as "write-only" documentation ....
>stuff that's written down, never to be looked at again :-)
>
>Is there a general consensus that these sorts of comments are
>Good Things, or a waste of time?  I, personally, care more
>about what the function _is_, rather than what it _was_.
>
>Inquiring minds want to know.
>
>--tom
>

There's been lots of discussion about this topic, via E-mail and in
comp.lang.c, so I thought I'd post a summary of the responses.

Most people agree that this sort of information is useful (and I never
intended to imply that it wasn't; just its usefulness in the source file.
That'll teach me to type so fast!)

The opinions were pretty evenly split amongst programmers who think that
the information should be actually in the source code, and those who think
it belongs elsewhere.  "Elsewhere" usually means some sort of automated
trouble report tracking system.

By far the most common argument for its usefulness was that automated tools
do it automatically.  Can't beat THAT logic!

To anyone who E-mailed me and got no response, sorry.  There were more
than a I could get to!

C you,
-- tom


Newsgroups: comp.software-eng
From: rcd@raven.eklektix.com (Dick Dunn)
Subject: Re: C code Layout
Organization: eklektix - Boulder, Colorado
Date: Wed, 16 Dec 1992 08:37:33 GMT

kanze@us-es.sel.de (James Kanze) writes:
>lfd@cbnewsm.cb.att.com (Lee Derbenwick) writes:
>|> One reason that I personally dislike very large comments embedded in
>|> the code is that they greatly reduce the amount of code within my
>|> visual field (whether on a screen or on paper):...
...

Scott McGregor talks about the same phenomenon (and some of the tradeoffs
surrounding it) in considerably more detail.  But it's a good point in any
case.

[Kanze applies name "band width theory"]
>the number of characters [the page] can contain, and the goal is to use
>this band width in an optimal fashion.)

This, by itself, seems a straightforward statement.  Since what we've been
talking about is, after all, how to convey information beyond what the code
itself says, isn't there some goal to use the available space in an optimal
fashion?  Not a "most compact" fashion, mind you..."optimal" refers to
"best", not "smallest".

>Of course, this means that you also put several short statements on
>the same line, code on the same line as the opening brace, etc...

No, it doesn't mean that.  Where is it written that "optimal" means
"extreme to the point of obvious stupidity"?

There are cases where you might put several short statements on a line, if
they're intimately related to one another.  For example,
	t = x0;  x0 = x1;  x1 = t;
This is a single operation, a simple "exchange x0, x1".  But the criterion
is not merely "short"; it is "intimately related".

And even K&R style, one of the more compact C styles, does not put code on
the same line as the opening brace.

In other words, you are trying to set up a straw man, and you have been
insufficiently subtle, so your device is found out even by dullards like
me.

>...And of course, you never, never leave a line blank.

More strawman.

>This also argues for short variable names.  (They increase the chances
>of getting more than one statement on a line.)

Apparently you've succeeded in ignoring the real reason for short variable
names--even though it's well known and has also been discussed here
recently: a common practice, in natural as well as artificial language, to
use the most compact forms for the most common words.

>In case it's not obvious from the tone of my comments, I am in total
>disagreement with this style.

In case it's not obvious from the tone of my reply, I am pointing out
that the "style" with which you totally disagree is an invention of your
own imagination.

The remainder of this discussion has mostly moved in the direction of
noting the endpoints of common usage and exploring the ground in between.
You do no service--unless you are simply looking for baseless argument--
by staking out ground outside where the rest of us stand, and arguing that
it is wrong.
-- 
Dick Dunn    rcd@eklektix.com   -or-   raven!rcd    Boulder, Colorado USA
   ...Mr. Natural says, "Use the right tool for the job."
Newsgroups: comp.software-eng
From: rcd@raven.eklektix.com (Dick Dunn)
Subject: Re: Just how sophisticated should we assume progrr & her/his tools to be?
Organization: eklektix - Boulder, Colorado
Date: Sat, 19 Dec 1992 06:37:29 GMT

jxm@engin.umich.edu (John Murray) writes:
>- The assumption that those who have to maintain one's carefully crafted
>  code will use (or even have access to) the vi editor, or any other 
>  given tool, is flawed...

OK, *one*more*try*: Nobody who illustrated finding "words" with vi implied
that vi was required.  It was used as an *example*.  Do I have to go out
and survey all of the PC editors and programming tools to prove that there
are decent editors available for the proletariat?

There was no assumption of any given tool.  The assumption was that if
you're going to be working on code, you'll have *some* editor with reason-
able capability for examining and modifying the code.  The level of capa-
bility assumed is really very low.

If you're going to pound nails, you need a hammer.  It doesn't have to be a
good hammer unless you're going to pound a lot of nails...but don't come
whining that nails are all wrong because you can't pound them with a rock.

>...Unfortunately, it smacks of elitism and perhaps
>  a professional desire to keep out the 'ill-informed'. [For precedents,
>  look at the legal and medical professions.] 

It's sad when someone has to sink this far to justify an idiosyncrasy.
This is just a straight "political incorrectness" gambit: "we can't expect
people to do [whatever-you-disagree-with] because that's elitism."

What's "elite" about expecting that a certain quality of tool (which REALLY
is very low, and can be had for free on common machines) be available to
someone who wants to write good code?

What's "elite" about writing code as if the people reading it mattered?

Where was there *ever* any slight hint of keeping out the "ill-informed"?
This is pure red herring with hot sauce.
-- 
Dick Dunn    rcd@eklektix.com   -or-   raven!rcd    Boulder, Colorado USA
   ...Mr. Natural says, "Use the right tool for the job."
Newsgroups: comp.software-eng
From: marick@cs.uiuc.edu (Brian Marick)
Subject: Re: Software Inspections. How many does it take?
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
Date: Sun, 20 Dec 1992 15:14:03 GMT

I like the approach given in David L. Parnas and David M. Weiss,
"Active Design Reviews: Principles and Practices", Proceedings of the
8th International Conference on Software Engineering, pp. 132-136.  If
I recall correctly, they advocate identifying a group of experts (in
the application area, interfaces to the hardware, maintainability, and
so on).  Rather than collecting all of these people for a meeting,
instead they're given the design and a list of questions to answer.
They answer these alone in their office.  People are convened only to
discuss problems.  When possible, the "questions" are in the form of
tasks, such as "Show how you'd use this design to cause the module to
do task FOO with your module BAR?", rather than just "Does the
module's interface to your BAR module look OK?"

(Some of this may be my later distortions of their original idea; read
the paper.) 

I try to use this approach in my inspections, and I use much the same
principle in my "question catalog for code inspections", available via
anonymous FTP from cs.uiuc.edu:/pub/testing/question.ps.  It seems to
be a useful adjunct to other tricks of the trade.

Brian Marick, marick@cs.uiuc.edu, testing!marick@uunet.uu.net
Testing Foundations:  Consulting, Training, Tools.
Freeware test coverage tool:  see cs.uiuc.edu:pub/testing/GCT.README




Newsgroups: comp.software-eng
From: mark neumann <neumann.m@apple.com>
Subject: Re: Software Inspections.  How many does it take?
X-Useragent: Nuntius v1.1.1d12
Date: Sat, 19 Dec 1992 01:47:19 GMT
X-Xxdate: Fri, 18 Dec 92 17:46:41 GMT
Organization: HomePro Computer Services

Re: Software Inspections.  How many does it take?

Glad that so many are questioning the "common wisdom" of having large
reviews.

Another question:  
In article <1992Dec17.231020.7917@eecs.nwu.edu> Travis Marlatte,
travis@eecs.nwu.edu writes:

>If I am making a small change or coding a small section that is fairly
>confined in the system, I really only need to have one maybe two people
>take a look at it. I'll probably throw a copy on their desk and ask them
>to take a look at it.

Is a meeting necessary to accomplish a review?  If the review is covering
a topic of interest to many, such as a high-level design review, then the
interchange of a meeting might accomplish a great deal.  But code review
should probably be done by passing a copy around for mark-up.  This
implies that the code can be reviewed "stand-alone" without the authors
explanation (just the way a maintenance programmer will have to review it
:>   ).

I have been to a lot of design reviews and quite a few code walkthroughs.
 The later never seemed to be cost effective, but Capers Jones book made
me reconsider.  I have tried techniques where, on larger projects, the
team leads (3-5 people per team) were responsible for reviewing all the
work of their team members.  If there were problems, their tail was on
the line too.  Unfortunately, that leaves little time for them to program.
--------------------------------------------
Opinions expressed are solely my own.
Newsgroups: comp.software-eng
From: mcgregor@netcom.com (Scott Mcgregor)
Subject: Re: Version Control - Software Configuration Change Management
Organization: Netcom - Online Communication Services (408 241-9760 guest)
Date: Fri, 18 Dec 1992 07:21:17 GMT

In article <1992Dec17.040941.5372@schbbs.mot.com> TENG63@waccvm.corp.mot.com (Steven Lynch) writes:

>Is anyone aware, please, of any systems which would control all of the
>information associated with a software project under some sort of
>version control?

Unfortunately, systems don't control these things, people do.  There
are however commercial products that can support doing these things.
Typical are the repository systems, such as Caseware/CM and Atherton
Software BackPlane. But there are also configuration management
systems such as Atria ClearCase and TeamOne in which the repository
looks more like a native file system.

Many people mix and match components from several vendors for best of class
solns: e.g. Caseware/CM for version control and configuration management, Merge
Ahead from Prescient Software for merging parallel development lines,
HP Softbench for intertool messaging, Remedy's change management
system for task management and traceability, etc.

-- 

Scott L. McGregor		mcgregor@netcom.com
President			tel: 408-985-1824
Prescient Software, Inc.	fax: 408-985-1936
3494 Yuba Avenue
San Jose, CA 95117-2967

Prescient Software sells Merge Ahead, the tool for Merging Text or Code and
offers consulting  & training in project management and design for usability.



Newsgroups: comp.software-eng
From: ssimmons@convex.com (Steve Simmons)
Subject: >>>  Value of High Code Coverage Metrics in Testing - Request for Opinion
Date: Mon, 14 Dec 1992 12:28:01 GMT
Organization: Engineering, CONVEX Computer Corp., Richardson, Tx., USA
X-Disclaimer: This message was written by a user at CONVEX Computer
              Corp. The opinions expressed are those of the user and
              not necessarily those of CONVEX.


Performing test coverage analysis on code is more of a good attitude than
it is a silver bullet for removing bugs.  There is an old mgmt saying,
"What is inspected is what gets done". 

> 1)  Do people think that this is a valuable metric?

Again, it improves the code but it does not remove all bugs. Design flaws
about cases not being handled cannot be found.  Also, any code that uses data
driven tables (e.g. finite state parsers) cannot be measured effectively. 

> 2)  Is it a cost effective excersize to get engineers to achieve a particular
>    %BFA as a completion criteria?

Sure... if you have the time in the schedule and effective tools to do it. 
Usually, it is best to have people do coverage analysis on their own code
and have people who don't know the code test it for unanticipated conditions.

> 3)  What is a realistic %BFA to aim for?

Fairly low percentage of 50% is usually the maximum possible value.  Much 
code is assertion testing.  However, every condition should be accounted. 

Thank you. 


						Steve Simmons
Newsgroups: comp.software-eng
From: phardie@nastar.uucp (Pete Hardie)
Subject: Re: C code Layout
Organization: Digital Transmission Systems, Duluth, GA.
Date: Thu, 17 Dec 1992 16:15:12 GMT

In article <1992Dec17.074616@eklektix.com> rcd@raven.eklektix.com (Dick Dunn) writes:
>I wish we had a way to get some useful objective data on this.  My hand-
>wave against the argument Pete presents is that the K&R style has one line
>at either end of the bracketed range, rather than two at the start and one
>at the end.

I handwave back that this marks conditionals (while, do, etc) better, to
call their importance out. 

(all this waving going on....creating quite a draft...)

>at the end.  Anyway, humans don't pay much attention to the brackets!  We
>use indentation.  Don't believe it?  Just try people on something like:
>	if (i <= 0)
>		mumble = 0;
>		return;

I agree that the visual nesting outperforms the textual, but neither brace
style seems to definitively correct this, since it's really an error in the
placement of any text.

>In general, if indentation fails to match the real nesting, people will
>"see" the nesting (wrongly) implied by indentation.  Also, if you give { a
>line by itself, you get the rather stringy
>	}
>	else
>	{
>instead of
>	} else {

To me, this 'hides' the else, making it less visible.  It also makes it
(slightly) harder to do a pattern search for ALL elses.  I can use /^else
with my indentation, while I need an optional pattern to find them with
your style.



-- 
Pete Hardie:  phardie@nastar  (voice) (404) 497-0101
Digital Transmission Systems, Inc., Duluth GA
Member, DTS Dart Team           |  cat * | egrep -v "signature virus|infection" 
Position:  Goalie               |
Newsgroups: comp.software-eng
From: lfd@cbnewsm.cb.att.com (Lee Derbenwick)
Subject: Re: C code Layout
Organization: AT&T
Date: Mon, 14 Dec 1992 23:55:21 GMT
Summary: BSD utilities != UNIX source code, plus large-comment maintenance.

In article <1992Dec14.175533.8400@fcom.cc.utah.edu>, bryant@ced.utah.edu (Bryant Eastham,MEB 3116,581-5353) writes:
> In article 074411@eklektix.com, rcd@raven.eklektix.com (Dick Dunn) writes:
> >Next, step back and look at where UNIX has gone.  That code has been read
> >and understood by tens of thousands of people, and has been successfully
> >modified over and over again for many years, often by people with almost no
> >training or aptitude.  Like it or not, there is massive evidence that the
> >style DOES work, IS understandable, and IS maintainable.  It's *not* the
> >only workable style!  But it works.
> 
> I suppose that explains why the examples of poor (very poor) commenting
> style for my senior lab class were from the source for UNIX! No lie,
> one assignment was to comment the command "strings", which (from the
> distribution) had (if I remember right) ONE COMMENT LINE. I don't know
> who that style works for. Certainly not anyone in the class or the
> instructors.

This is a poor counterexample, because the "strings" command was
added by someone at UC Berkeley; it's unfair to count it as part of
the UNIX source code cited by Dick Dunn.  Certainly not in a thread
that had mentioned Kernighan and Ritchie.  From your description of
the source code, it doesn't sound as if strings.c was commented in
anything resembling "K&R style".

One reason that I personally dislike very large comments embedded in
the code is that they greatly reduce the amount of code within my
visual field (whether on a screen or on paper): they increase the
number of fingers I need to read the code.  [An interesting
"difficulty" metric that I've seen attributed to Tom DeMarco.]

Another reason, potentially more damaging in the long run, is that
long comments don't seem to be maintained as well as short ones.
Somebody changed the code, but didn't go back to update the fourth
line of the fifteen-line comment back at the beginning of the loop.
So the comment now lies about what the code is doing.  That seems
to happen far less often with concise comments attached to the code
they describe.

This second problem may also occur with literate programming
systems. They are still too new to have had large, production code
maintained for several years in them.  It will be interesting to
see if they avoid the problem of the text being less-maintained
than the executable code itself.

 -- Speaking strictly for myself,
 --   Lee Derbenwick, AT&T Bell Laboratories, Holmdel, NJ
 --   lfd@cbnewsm.ATT.COM  or  <wherever>!att!cbnewsm!lfd
From: poneill@amsaa-cleo.brl.mil (Pat O'Neill)
Newsgroups: comp.software-eng
Subject: Cyclomatic Complexity vs Fault Rate
Keywords: cyclomatic complexity, fault rate
Date: 15 Dec 92 00:34:50 GMT
Organization: U.S. AMSAA


	I am looking for any studies or data that relate McCabe's
cyclomatic complexity to fault rate per line of code. I am particularly
interested in any such studies involving military systems.
	Thanks in advance to any replies of pointers to info.
		
					Patrick J. O'Neill
					U.S. AMSAA
Newsgroups: comp.software-eng
From: shanks@saifr00.cfsat.honeywell.com (Mark Shanks)
Subject: Re: Software Inspections.  How many does it take?
Organization: Honeywell Air Transport Systems Division
Date: Fri, 18 Dec 92 14:59:52 GMT

In article <BzEqpI.5yp@NeoSoft.com> claird@NeoSoft.com (Cameron Laird) writes:
		.
>I have no experience with reviews in which the
>author(s) is (are) *not* present, but I like
>the idea; is there anyone who can report on how
>that works in practice?
>
>My attraction to this has nothing to do with
>"ego"; I just want to have the documents stand
>on their own, without the explanations that the
>author(s) inevitably carri(es).

I suppose this begs the question, but what is intended to 
be accomplished at the review? If the software is expected to
be maintained by someone other than the author (and THAT'S a
good possibility), it makes some sense to me that the software
ought to be able to "stand on its own". But what are all
these other characters doing? The "moderator" (read "facilitator"
in more fashionable circles) is an excrescence; if you can't
get a group of professionals to conduct an inspection without
this person, you don't have a group of professionals. Who is
the "scribe" (a term that because of my upbringing conjures
up images of cowled monks illuminating gospels) and what
EXACTLY are they doing, collating defects? Flame me if you
like, but I think that's what SQE should be doing. I see a 
HELL of a lot of hours spent on inspections, which is not
bad in itself, but when you multiply how many people are
involved, there must be a point of diminishing returns.
IMHO, the duties of moderator and scribe can and should be
assumed by SQE. As another has posted, the more designated
inspectors involved, the less each individual is likely to
feel responsible for actually inspecting, and the review
turns into a nit-pick ritual.

Let me start some new threads: WHEN should software be inspected?
Or: How many times should software be inspected prior to
initial delivery? Should software be inspected and put into
a configuration management system months before design is
complete and months before scheduled delivery, i.e., at a
Critical Design Review stage? What are the differences between
a formal and informal inspection?

Just asking ;-)

Mark Shanks
shanks@saifr00.cfsat.honeywell.com
From: msains@ibis.ru.ac.za (Malcolm Sainsbury)
Newsgroups: comp.software-eng
Subject: Best grad schools for Information Systems
Date: 16 Dec 92 07:06:14 GMT
Article-I.D.: ibis.msains.42.724489574
Organization: IS Department, Rhodes University

A colleague of mine has a sabbatical year coming up (June 1993) and
is investigating postgraduate study (Masters level) in the USA.  His
major interests are in Software Engineering, with particular enthusiasm
for high-level development tools and environments.  

He asked me to recommend some good USA programmes, but I realise that
I have lost touch over the past three years.  Could members of this 
group please suggest some excellent grad schools he could contact and 
provide any information about their programmes that might help.

Since his year has been almost fully sponsored in advance, cost is not a 
major factor in choosing a good school.  He also has a very solid academic 
record so will almost certainly be accepted by most good schools.

If you post suggestions in this group I will see that he gets them.

Malcolm
--
Malcolm Sainsbury - Dept of Information Systems - Rhodes University
Internet: msains@ibis.ru.ac.za                 Phone: +27 [0]461 22023 xt 244
    uucp: ..!uunet!m2xenix!quagga!ibis!msains    Fax: +27 [0]461 25049
Newsgroups: comp.software-eng