HDTenEightyP/NetNews huggingface dataset:
From: neumann.m@applelink.apple.com (mark neumann)
Newsgroups: comp.software-eng
Subject: Software Inspections.  How many does it take?
Date: 14 Dec 92 19:20:08 GMT
Organization: HomePro Computer Services

Recently I have been reading Capers Jones new book "Applied Software
Measurement", McGraw Hill.   There is a lot of good stuff in it, but one
recommendation he makes on the topic of software inspections does not
match my experience.

He presents some statistics showing software inspections (design reviews,
code walkthroughs, etc..) as being the most effective way of removing
defects.  However, the inspection technique he describes  requires a
bunch of people! (he lists the following staff as being present):

"  * A moderator (to keep discussions within bounds)
   * A reader (to paraphase the work being inspected)
   * A recorder (to keep records of all defects)
   * An inspector (to identify any problems)
   * An author (whose work is being inspected)

All five (or more) may be present for large projects.  For small projects
dual roles can be assigned, so that the minimum number for a true
inspection is three: moderator, author, and one other person. "

For high-level architecture/design approach type reviews, everyone
affected needs to be involved.  But what about module level design/code
inspections, where the work being inspected is the result of one persons
effort?

In my experience, when the schedule pressure is on, most of the attendees
at large formal code walkthroughs are too busy with their own work to
carefully go over the material being reviewed.  This diminishes the
effectiveness of the review.

It seems obvious that having someone check your work is a good idea.  It
also seems that each additional person that checks your work is less
likely to find a problem (on average).

My question:  Is one person enough?  Does anybody else use a single
reviewer approach?

I believe that there are interpersonal dynamics which make one reviewer
more effective than two of more.  With two or more people, the ego of the
person whose work is being reviewed is more likely to become a factor.

Finally, by assigning a single reviewer to inspect someone elses work,
that person is obviously  responsible for any flaws that get through, so
he/she is likely to take the role seriously. (Note: you probably do not
want to assign people to inspect each other's work, since they may agree
to just trust each other completely).
--------------------------------------------
Opinions expressed are solely my own.
Newsgroups: comp.software-eng,comp.human-factors
From: eivind@idt.unit.no (Eivind Throndsen)
Subject: Prototyping tools, anyone?
Followup-To: comp.software-eng
Summary: List of good ones requested
Originator: eivind@boek
Keywords: prototyping tools
Organization: Div. of CS & Telematics, Norwegian Institute of Technology
Date: Fri, 18 Dec 92 12:51:27 GMT

This is probably, or it should be a FAQ. Since I have not seen it
mentioned yet (new on this list) I am asking.

Does anyone have a list of good, suitable PC or UNIX user interface
prototyping tools for _large_ systems? I.e. Windows- or terminal-based
screen painters with a good degree of functionality, soitable for
prototyping complex applications. Please e-mail, I will summarize.

Thanks.

-- 
Eivind Throndsen (eivind@idt.unit.no)  
From: defaria@hpcuhe.cup.hp.com (Andy DeFaria)
Date: Thu, 17 Dec 1992 00:17:17 GMT
Subject: Re: C Code Layout
Organization: Hewlett Packard, Cupertino
Newsgroups: comp.software-eng

>/ hpcuhe:comp.software-eng / phardie@nastar.uucp (Pete Hardie) /  7:38 am  Dec 15, 1992 /

>A brief comment (NPI :->) here.  I find that the brace style:
>
>	if(condition)
>	{
>		statement;
>		...
>	}
>
>is more readable than this style:
>
>	if(condition) {
>		statement;
>		...
>	}
>
>for one main reason - the alignment of the open and close braces is the same,
>and this (to me) ties the block of code together.  IMHO, this outweighs the
>additional single line per block of vertical space.

That's because you view it as an open ({) and corresponding close (}).  To me,
such statements, while they require a close, should not require an open.  In
other words the assumption should be that I always have a compound statement
and must tell the compiler when it's done.  C required that I also specify an
open but I see no reason to devote a full line to it!  I detest:

	if (condition)
	   statement;
        statement;
or 	
	if (condition) statement;
	statement;

It's just too easy to misread the fact that C will only execute the first
statement if condition is true.  I would code:

	if (condition) {
	   statement;
	} /* if */

	statement;

Note I label my terminating close (}).  Now think about it.  When eyeballing
the above code and reading the if statement: Do you really care where it has
opened or when it has closed?  To me the open is inconsequential: Of course it
starts but where does it end?  Consequently:

	if (condition) {
	   statement;
	} else {
	   statement;
	} /* if */

Here you again scan the if statement and ask yourself: "OK if this condition
is true I'll be executing this code here.  OK where does it end?  Hmm.. Oh
here is the else portion and this is executed if the above if is false.  OK
and this whole if terminates at... A ha here's the terminating brace".

At least this is how I find myself reading code.

Newsgroups: comp.software-eng
From: claird@NeoSoft.com (Cameron Laird)
Subject: Fitting the pieces together (was: What is Software Design?)
Organization: NeoSoft Communications Services -- (713) 684-5900
Date: Thu, 17 Dec 1992 14:05:33 GMT

In article <1992Dec15.013037.6513@latcs1.lat.oz.au> baragry@amdahl1.lat.oz.au (Jason Baragry) writes:
			.
			.
			.
>	People I have talked with (programmers) then argue that if we did 
>that for software our diagrams would be to complex because our implementation
> medium is the programming language.
>	This is then the point where we have to look at our view of
> implementation medium. Should it be the programming language level ? I agree
>with the article in IEEE Software (Nov 90) by Brad Cox, which discusses
>objectifying software modules. This is the type of implementation medium I 
>believe we should be looking at. Modules with a defined functionality, which 
>may be implemented in any way (OO, proceduraly, rules, etc) but can be
>"fitted together" to construct a design which represents the implementation.
>
>	I am currently working on a design method which would support such 
>ideas (but it is still relatively earrly).
			.
			.
			.
>I can see what you are saying, but I think it means generating components in the
>design which are represented by the implementation medium. Instead, of moving
>code further up the design process I think it means using high-level 
>components with predefined functionality which can be implemented by a piece
>of previously implemented code.
			.
			.
			.
Please note that comp.lang.misc (and comp.compilers?)
recently has (have) entertained some low-key dialogues
on definitions of interfaces between implementation
languages.  That is, people have been discussing such
questions as, "Should we standardize as part of C a
way to access FORTRAN subroutines?" and "What does it
mean to send a message to a COBOL object ('object'?)?"
and "How does Eiffel handle that?"
-- 

Cameron Laird
claird@Neosoft.com (claird%Neosoft.com@uunet.uu.net)	+1 713 267 7966
claird@litwin.com (claird%litwin.com@uunet.uu.net)  	+1 713 996 8546
Newsgroups: comp.software-eng
From: mueller@b30.ingr.com (Phil Mueller)
Subject: Re: C CODE LAyout
Organization: Intergraph
Date: Tue, 15 Dec 1992 13:43:47 GMT

In article <1992Dec15.131848.22744@b30.ingr.com> mueller@b30news.b30.ingr.com ( Phil Mueller ) writes:
>In article <MARTINC.92Dec11214534@hatteras.cs.unc.edu> martinc@hatteras.cs.unc.edu (Charles R. Martin) writes:
>>
>> [stuff deleted]
>>
>>I frankly have always found it very difficult to believe that anyone who
>>suggests such a style has any professional software engineering
>>experience.  My experience has *always* been that, on examination, the
>>people who discourage detailed comments in code have spent their entire
>>professional career in academic settings, writing code in a small group,
>>with relatively little maintenance of code by anyone other than the
>>author, and in general with products of only a few thousand lines of
>>code.
>>
>
>I code with very few comments ( other than the infamous header ).
>10 years at Intergraph.
>10 programmers + support personnel ( i.e. management ). 
>  ( not sure how this compares with other shops ).
>with turnaround
>plenty of maintenance by other people.
>900000 lines in 6 years.
>( first 2 years not a programmer; next 2 years on a failed project ).

Let me clarify that.
10 years at Intergraph, first 2 not a programmer, next 2 as a programmer
on a project that failed, last 6 on current project which is doing
very well.

-- 
Phil Mueller    mueller@b30news.b30.ingr.com
"My invention today is the Steve-a-meter.  If you have a nifty idea you just-"
"Beep! beep! beep! beep!" 
"Oh no!  Steve Allen thought of .signature files first!?!?!?"
Newsgroups: comp.software-eng
From: jld@datascope.com (Jay L. Davis)
Subject: Re: C code Layout
Keywords: C code layout
Organization: Datascope Corp.
Date: Tue, 15 Dec 1992 16:04:08 GMT

In article <1992Dec12.122453.8582@seq.uncwil.edu> herbst@seq.uncwil.edu (R.T. Herbst) writes:
>While directing the eforts of 125 people in producing the 
>A Data switching system for the Bell System- Good ol'
>Ma bell-- I asked for a sample of code. I founr the comments to
>be utter nonsense,. If one removed the code, the comments made no sense.
>It was better to let the code speak for itself. If fact the code
>was hidden in by the comments. Certainly we need well commented code.
>Too many comments that try to say what the code is saying are IMHO
>distracting. The code in this case was assembler. Since that time
>higher level languages came into use. In particular C language.
>My philosophy is to let the language speak for itself. Add comments
>where necessary. Again while directing the efforts of hundreds of
>people on the Safequard Anti-Balistic Missile System, we set standards
>for commenting that let the code be seen. The project met its objectives
>and schedule -- one of the few in that time frame. 
>Flame on and damned be he or she who flames out.

About time I heard some common sense in this discussion. One other point that
is real important, if your code is a maze, you need a detailed map. If it
is organized (designed) well, you don't have to explain it as much, it should
be obvious.

---Jay Davis
Newsgroups: comp.software-eng,comp.lang.c
From: rcd@raven.eklektix.com (Dick Dunn)
Subject: Re: C Code Layout
Organization: eklektix - Boulder, Colorado
Date: Fri, 11 Dec 1992 16:58:35 GMT

scott@yarc.UUCP (Scott Beckstead) writes:
>tomj@monster.apd.saic.com (Tom Johnson) writes:
[example of revision author/date/synopsis list
>>I've always wondered about this sort of thing in a source file.
>>Is this sort of information considered useful?...

Realize again (as others have noted in passing) that "is this...useful?" is
a separate question from "should it be in a source file?"  Lots of us will
say it's indispensable, but doesn't belong in the source itself; it belongs
in the information kept by the control system, where you can get to it if
you need it but it's not constantly in your face.

Scott then talks about noting each change in the source itself:
>...Tags were left in the source of the form /*SHB01A.1*/ at each
>changed location. It was then quite clear when/why the change was made
>and related this to the top line that had this tag...

This only works for a little while.  It doesn't scale to longer-term
development, because the source code gets so cluttered with these little
comments that you really can't understand their relationship any more.

>...This technique was MUCH better than
>trying to diff  a file that may have been changed 5 or 6 time before I
>had to look at it...

Your code-control system ought to be able to hand you a "diff" representing
the changes between any two given revisions.  For the differences between
two consecutive versions, it's about a wash for comments in-line versus the
diff.  If you're stuck in the (all too common) situation of "it worked in
version 37; it's broken in 42" you'll most likely want to see the
accumulation of changes between those versions...including the fact that
some changes may have been made, then undone.  Also, what the code does is
(at least arguably) more important than what it did--in the sense that the
contents of the code should be most useful to the person working on it as
it stands.  Change archaeology is important but should take a back seat.

But some of that issue--how to understand the changes--is obviously depen-
dent on how people work and look at code.  My main point is that it doesn't
extend to long-term development...I've actually watched it fail.  Took
about a year of relatively active development to make source code nearly
unreadable.
-- 
Dick Dunn    rcd@raven.eklektix.com   -or-   raven!rcd    Boulder, Colorado
	...Straight, but not narrow.
From: martinc@hatteras.cs.unc.edu (Charles R. Martin)
Newsgroups: comp.software-eng
Subject: Re: C code Layout
Date: 15 Dec 92 12:58:50 GMT
	<1992Dec15.073140@eklektix.com>
Organization: UNC Department of Computer Science
In-reply-to: rcd@raven.eklektix.com's message of 15 Dec 92 07:31:40 GMT

In article <1992Dec15.073140@eklektix.com> rcd@raven.eklektix.com (Dick Dunn) writes:

   As noted elsewhere, that's Berkeley and not B'Labs.  OK, I'd find it hard
   to believe that strings could get away with one comment.  

I've never looked in strings, but here is the complete comment from
script.c ....

	/*
	 * script
	 */
--
		Charles R. Martin/(Charlie)/martinc@cs.unc.edu
     Dept. of Computer Science/CB #3175 UNC-CH/Chapel Hill, NC 27599-3175
	    3611 University Dr #13M/Durham, NC 27707/(919) 419 1754
     "Oh God, please help me be civil in tongue, pure in thought, and able
      to resist the temptation to laugh uncontrollably.  Amen." -- Rob T
Newsgroups: comp.software-eng
Subject: Re: Putting Engineering into Software Engineering
From: baragry@amdahl1.lat.oz.au (Jason Baragry)
Date: Sun, 20 Dec 1992 23:47:13 GMT
Organization: Comp Sci, La Trobe Uni, Australia

In article <BzHKr6.DGr@fiu.edu>, feathers@serss0 (Michael Feathers) writes:
|> 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.
|> >
[...]
|> >
|> >All of these illustrate what software is missing.
|> >-- 
|> 
|> 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.
|> 

	I think the difference is that in other engineering disciplines these
modelling / analysis techniques provide a way to analyse the properties of the
components which constitute the system. In these engineering fields there is
a high level of reuse and to compare components you need some way of
representing the properties of these components.
	Sure, algorithms in SE can be measured by speed but if I am looking
at which electronic components I would want to reuse to meet my needs I can
use circuit analysis, frequency & phase analysis, transmission line theory,
etc to do it. How can I analytically compare to high-level SE components to
see which one meets my needs the best? (assumming people may one day actually
think like this!) I have to rely on written documentation of what the thing
does and how the thing does it. Perhaps there isn't any way of modelling high
level SE components. Perhaps the only way to compare SE modules without
simply relying on documentation (which is very quantifiable) is to animate
those components and compare their operating performance.

Jason.

-------------------------------------------------------------------------------
Jason Baragry.			|	Amdahl Australian Intelligent 
Dept Comp. Sci. & Comp. Eng.,	|		Tools Program
La Trobe University.,		|	baragry@latcs1.lat.oz.au
Bundoora. 3083.			|	Phone:	+61 3 479 1477
Australia.			|	Fax:	+61 3 470 4915
--------------------------------------------------------------------------------
Newsgroups: comp.software-eng
From: phardie@nastar.uucp (Pete Hardie)
Subject: Re: C code Layout
Organization: Digital Transmission Systems, Duluth, GA.
Date: Fri, 18 Dec 1992 15:50:57 GMT

In article <454@casemo.UUCP> keating@casemo.UUCP (John Keating ) writes:
>I prefer the following:
>        if (condition)
>          {
>            statement ;
>            ...
>          }

I find it distracting, the two levels of indentation.  Also, it means you
need to have a very small tab, or use spaces, which seems too typing-intensive
for my taste.

One thing I have toyed with is using indent and/or cb in combo with SCCS/RCS
to store the source in an unindented format, and let each developer specify
in a file the preferred format s/he would like to see the code in, and have
the check-out process format code for them, and the check-in process remove
all formatting.

-- 
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: claird@NeoSoft.com (Cameron Laird)
Subject: Exception-handling, as usual (was: Value of High Code Coverage Metrics in Testing - Request for Opinion)
Organization: NeoSoft Communications Services -- (713) 684-5900
Date: Thu, 17 Dec 1992 14:36:08 GMT

In article <johnr.724486714@pongo.kowari.cpsg.com.au> johnr@bohra.cpg.oz.au (John Reid) writes:
                        .
                        .
                        .
>I often have to persuade programmers to try data values that should never
>be acceptable, but for commercial applications, your code should be robust
>enough to deal with any values. If your input program, say, is accepting
>data, and only numeric data can be used by the appliication, then you need
>to know that if you are silly enough to enter "FRED" the program will
>identify your deliberate mistake and tell you about it, rather than
>blithely attempting to calculate the size of a concrete beam with a safe
>working load of FRED tonnes (How heavy is Fred, anyway ??:-), assuming that
>that was what your program was to do.
                        .
                        .
                        .
I'll bet you do "have to persuade programmers ..."
Do any of our psychologically-sophisticated discus-
sants have an explanation for this?  In my experience,
one of the toughest jobs a newcomer from an academic
environment has is learning why, "But the user never
should do that anyway," is not a conclusive argument.

I'm not saying that the academic world should be a
trade school, and I apologize a bit for my obses-
siveness on the topic, but I look forward to a day
when I don't *have* to be so compulsive ...
-- 

Cameron Laird
claird@Neosoft.com (claird%Neosoft.com@uunet.uu.net)	+1 713 267 7966
claird@litwin.com (claird%litwin.com@uunet.uu.net)  	+1 713 996 8546
From: claird@NeoSoft.com (Cameron Laird)
Subject: When do we inspect (was: Software Inspections.  How many does it take?)
Organization: NeoSoft Communications Services -- (713) 684-5900
Date: Sun, 20 Dec 1992 04:53:08 GMT

In article <1992Dec18.145952.26062@saifr00.cfsat.honeywell.com> shanks@saifr00.cfsat.honeywell.com (Mark Shanks) writes:
			.
			.
			.
>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
			.
			.
			.
Yes.

I assert:  source code should go into the CM system
from its first day.  Stay close to reality (the con-
ditions of approved delivery) all through development,
and find problems sooner, rather than later.  Some ob-
ject that checking in source is too much overhead; for
me, that's only a symptom that the check-in process
isn't yet adequate.  Coders should *want* the benefits
of even the most rudimentary CM:  automated regression
testing, static semantic analysis, validation of
porting considerations, ...
-- 

Cameron Laird
claird@Neosoft.com (claird%Neosoft.com@uunet.uu.net)	+1 713 267 7966
claird@litwin.com (claird%litwin.com@uunet.uu.net)  	+1 713 996 8546
Newsgroups: comp.software-eng
From: phardie@nastar.uucp (Pete Hardie)
Subject: Re: C code Layout
Organization: Digital Transmission Systems, Duluth, GA.
Date: Tue, 15 Dec 1992 15:38:59 GMT

In article <1992Dec15.073140@eklektix.com> rcd@raven.eklektix.com (Dick Dunn) writes:
>It explains some of the
>nuances of the "One True Brace Style" (the K&R positioning of braces),
>which seeks to minimize wasted vertical space.

A brief comment (NPI :->) here.  I find that the brace style:

	if(condition)
	{
		statement;
		...
	}

is more readable than this style:

	if(condition) {
		statement;
		...
	}

for one main reason - the alignment of the open and close braces is the same,
and this (to me) ties the block of code together.  IMHO, this outweighs the
additional single line per block of vertical space.

However, for some reason, I detest the indention of the braces, like this:
	if(condition)
		{
		statement;
		...
		}
although I can't come up with a single rational reason.



-- 
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: "Lih Yen Hsieh" <wk01673@worldlink.com>
Subject: Re: C Code Layout
Organization: [ Myself ]
Date: Fri, 11 Dec 1992 22:44:33 GMT
X-Mailer: WORLDLink (3.11)

Tom Johnson <tomj@monster.apd.saic.com> writes:
>
>mueller@b30news.b30.ingr.com ( Phil Mueller ) writes:
[ ommisions ]
>
>>HISTORY
>>       Author     Date          Description
>>       -----      ----          -----------
[ omissions ]
>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_.

I will be amazed if "software engineers" were cited in the counter point.
Inclusion of historical information about the module certainly helps track
the evolution of the piece of code of interest.  Points of relevance:

1. When you need to deal with FDA audits.
2. When you have to inherit code from previous contributors.
3. WHen you work on a project that contains at least dozens of source files.
4. When you are working on complex modules.
etc.

Practically, if you are in a production environment, this is not only
a good thing to have, but also indispensible and should be enforced.
(I was able to get by without documenting code history when I was
programing for my master's thesis work. But now at work I enforce it.)

If you are familiar with Unix tools, such as sed, awk, and the like, you
can craft non-trivial tools together with revision control and the make
program to somewhat mechanize this 'chore'.

Lih-Yen Hsieh

Newsgroups: comp.software-eng