HDTenEightyP/NetNews huggingface dataset:
From: dichter@chdasic.sps.mot.com (Carl Dichter)
Subject: Re: Productivity vs. Complexity
Organization: SPS
Distribution: na
Date: Sun, 22 Nov 1992 20:22:06 GMT

In article <1992Nov20.014919.10220@spectrum.xerox.com>, leisner@wrc.xerox.com ( Marty Leisner) writes:
|> Travis Marlatte (travis@eecs.nwu.edu) wrote:
|> : 
|> : Training a person to design a software system is no different than
|> : training that person to design a hardware system. It takes basic
|> : engineering skills refined for a particular discipline.
|> : -- 
|> 
|> Wow!!
|> 
|> Electrical engineers will agree on a good design.  Software engineers generally won't.
|> 
|> I think writing software is as much "enginnering" any type of creative activity,

It does require creativity, but that doesn't mean it can't be taught.

There is a reason that hardware engineers can agree about the attributes of 
a good design: the metrics been decided, and taught in school for many years.

Examples are Design for Testability, area and cost economies, speed, expandability,
and so on.

Values are learned, they are not automatically present in a new discipline, but
some are carried over from existing disciplines.
Electrical engineering is almost a hundred years old, software engineering 
is younger than most baby-boomers.

Fair criteria for good designs is, and must continue to be, established and
improved. 

Criteria for good programmers has been discussed a lot recently. Here's
two views:

 The problem with some programs (to use Wall and Swartz's values as an example)
 is that the programmers were not "lazy" enough to do it right the first time and
 to use existing code where possible, not "impatient" enough to put out a prototype 
 (and let the user's bang on it), and don't have the "hubris" to put some of
 themselves (creativity and effort) into their work.

 To put it Yourdon's way (Decline of the American Programmer), most engineers today 
 have the mind-set of auto workers in the 70's: they are ignorant and indifferent about 
 quality, productivity, the customers needs, and foreign competition. Personally,
 I don't think that the auto workers, or todays programmers, are THAT bad-- but
 you get the idea.

----------------------
Carl R. Dichter               "iwannanugui"
Motorola ASIC Division
email: dichter@chdasic.sps.mot.com
/*
** "People who never make mistakes work for people who dare to."
*/
Newsgroups: comp.software-eng
From: figueroa@jimminy.serum.kodak.com (Janet Figueroa (x37973))
Subject: Software Reliability - how to calculate?
Followup-To: comp.software-eng
Summary: Require reference for software reliability calculation
Keywords: software reliability reference calculation
Reply-To: figueroa@serum.kodak.com
Organization: Clinical Diagnostics Division, Eastman Kodak Company
Distribution: na
Date: Tue, 17 Nov 1992 18:21:19 GMT


I just had an interesting discussion with a peer who is an electrical engineer.
It was about our reliability budget in which we have set a goal of a certain
number of service calls per year upon the introduction of the instrument. 
She asked if there was a methodology followed in calculating relaibility for
software.  One of the examples we were discussing was code that resides in
a PROM.  If there was an error in the software and our service representative
will have to replace the PROM, how would that be looked at?

I told her point blank that I was not aware of any process used to
calculate software reliability.  Is there one?  I would be very
interested to know how the reliability is measured in an application
programming environment as compared to how it is determined for a
device driver, for example.
 
Any insights would be appreciated.  Thank you very much
 
Janet C. Figueroa
figueroa@serum.kodak.com



Newsgroups: comp.software-eng
From: leisner@wrc.xerox.com ( Marty Leisner)
Subject: Re: Productivity vs. Complexity
Reply-To: leisner@eso.mc.xerox.com
Organization: Xerox
X-Newsreader: TIN [version 1.1 PL7]
Distribution: na
Date: Mon, 23 Nov 1992 17:18:45 GMT

Programming can be taught...and learned...but the quality of the student is what matters...

Digital designs are as new as software...but there is far more agreement between good
digital designs than software.

I think software is far too abstract to be easy to be easily teachable...

--
marty
leisner.henr801c@xerox.com  leisner@eso.mc.xerox.com
Member of the League for Programming Freedom
From: cec@planet.bt.co.uk
Newsgroups: comp.software-eng
Subject: Making Quality Work
Date: 23 Nov 92 15:18:09 GMT
Distribution: planet,world
Organization: DNM42, BT Labs, Martlesham Heath, Ipswich, UK.
Originator: cec@phoenix


Hi

Does anyone know more about a publication called

Making Quality Work, Lessons from Europes Major Companies.

Thanks in advance

Chris Cox
Newsgroups: comp.software-eng
From: travis@eecs.nwu.edu (Travis Marlatte)
Subject: Productivity vs. Complexity
Organization: Rauland-Borg Corporation, Skokie IL
Distribution: na
Date: Wed, 18 Nov 1992 23:52:35 GMT

If we look at software as an extension of hardware (which it is), then
the time it takes to design a software system of X complexity should take
as long as designing a hardware system of X complexity.

We seem to look at the time it takes to develop software and wonder why
it takes so long - looking for ways to improve productivity.
At the same time, if we would consider using hardware
to solve the same problem, there would be alot of head nodding and
people saying, "It will never work!"

After all, there is just as much X in both designs, its just a different
implementation language. To ask a question, has software given us any new
tools for solving more complex design problems with less effort. I
don't think so.

Software has allowed us to quicken the implementation process and make
maintenance easier. Remember, I am comparing software and hardware
systems that have the same complexity. The design process should be the
same.

With the system implemented in software rather than hardware, it is now
possible to delay design decisions until late in the product life - like
until a customer stumbles across a missing piece. We use this technique
to shorten the design process to account for some portion of the total
design because we know we can modify it easily later.

In situations where we have to embed the software in a masked part, you
can be sure that more design effort will be expended - unless of course
the people working on the project don't understand the cost of re-masking
a part.

We do this in hardware too but much less frequently because the cost of
after-market modifications is well known.

Training a person to design a software system is no different than
training that person to design a hardware system. It takes basic
engineering skills refined for a particular discipline.
-- 
Travis Marlatte
travis@eecs.nwu.edu
708-297-0055
From: kambic@iccgcc.decnet.ab.com (Bonus, Iniquus, Celer - Delegitus Duo)
Newsgroups: comp.software-eng
Subject: Re: Software Designs
Date: 20 Nov 92 10:05:55 EST

In article <1992Nov19.040908.6796@netcom.com>, mcgregor@netcom.com (Scott Mcgregor) writes:
[...]
 But in the project databases I have
> looked at this assumption is easy to disprove.  In fact, the duration
> of the previous projects done by the individuals, or authorized by the
> management usually has significantly more explanatory power and thus
> yields better predictive estimates.  A lot of people don't like the
> fact that this is so.  They WANT models that are more dependent on
> things like complexity than on organizational or individual
> history--so they still prefer CoCoMo despite real evidence questioning its
> base assumptions.  
I are confused'.  The largest single factor in the COCOMO (different spelling?
- no wonder) is the personnel and team capability.  It seems that COCOMO agrees
with you rather than disagrees.  Is there something different about the
calibrated databses that you have looked?  COCOMO does nothing for you unless
it is used for a while, calibrated, and improved.

BTW, I agree with your point about application domains.  Software must retain 
the real world in its requirements.  What we do it real, and impacts people (
and sometimes the ground!).

George Kambic
sd

Newsgroups: comp.software-eng
From: garth@helix.ObjecTime.on.ca (Garth Gullekson)
Subject: Re: wanted info on OO design methodologies
Reply-To: garth@objectime.on.ca (Garth Gullekson)
Organization: ObjecTime Limited
Date: Tue, 17 Nov 92 14:09:41 GMT

In article <Bxtxyp.6Ez@brunel.ac.uk>, cs89ssg@brunel.ac.uk (Sunil Gupta) writes:
|> 
|> Id like to find out more details on Object Oriented development, especially 
|> on the following methodologies by the following people
|> 
|> 	Booch
|> 	Buhr
|> 	Rumbaug
|> 	Wirfs-brock
|> 	Yourdon-Coad
------------------------------------------------------------------------------

You may be interested in an OO methodology called Real-Time Object-Oriented
Modeling (ROOM) and an associated CASE tool (ObjecTime). The following
is a quick summary. If you or anyone else on the net wants more information
on it, please contact me.

	- Garth Gullekson -


ObjecTime Summary
-----------------

ObjecTime 4.0 is a commercial object-oriented CASE tool specifically
created for distributed, event-driven systems. 

ObjecTime supports an advanced methodology for the analysis and design
of distributed, event-driven systems known as Real-Time Object-Oriented
Modeling (ROOM).  ROOM includes graphical design concepts and a
highly-iterative development process which help to eliminate
error-prone discontinuities between the various phases of software
development.  As a unique feature, ObjecTime enables the creation of
executable analysis and design models that can be tested in an
extensive workstation-based run-time environment.

The high-level design concepts supported for real-time include
concurrent objects (hierarchically decomposed) that communicate via
messages through formal protocol definitions. Complex hierarchical
finite-state machines specify the behavior of such objects, via major
object-oriented extensions to the Statecharts formalism.  Inheritance
can be applied at the design component level, independent of the detail
level programming language.

The high-level object-oriented concepts are independent of programming
language. Either C++ or Rapid Prototyping Language (based
on Smalltalk-80) may be used at the detailed design level.

ObjecTime is vended by ObjecTime Limited, an independent software
company established as a spin-off from Bell-Northern Research (BNR),
the R&D arm of Northern Telecom. The development of ObjecTime started
in 1986 in a response to the needs of complex telecommunications
software design. It has been marketed since early 1991.

* * *

FOR FURTHER INFORMATION: 
 
	Garth Gullekson 
	ObjecTime Limited
	1-800-567-TIME
	sales@objectime.on.ca


Newsgroups: comp.software-eng
From: johnson@cs.uiuc.edu (Ralph Johnson)
Subject: Re: Will we keep ignoring this productivity issue?
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
Date: Tue, 17 Nov 1992 21:59:28 GMT

shanks@saifr00.cfsat.honeywell.com (Mark Shanks) writes:

>In article <1992Nov16.090509.22236@mole-end.matawan.nj.us> mat@mole-end.matawan.nj.us writes:

>>In other words, the manager has to have an appreciation of the `useful
>>art' of programming!  Which means they have to be good programmers themselves.

>I strongly disagree. With no desire to cast aspersions upon the value of
>good programers, in my experience the abilities required of a good
>manager are completely different than those required by a good programmer.

You are both half right.  Managers have to have an appreciation of
programming, but they don't have to be good programmers themselves.
They need to be able to read two programs and tell which is easier
to understand, which is faster, and which is more robust.  On the
other hand, a manager needs a whole bunch of abilities that a programmer
won't have.  Being a good manager is *harder* than being a good programmer.
If you are going to manage programmers than you have to know something
about programmers (note: not be as good as them, just be able to tell
who is doing a good job and have some idea of what the people who
are having troubles need to do to improve).  Good managers must be
able to deal with people, and many good programmers are not good at
this.  But this doesn't excuse managers from understanding what they
are managing.  The idea that any good manager can manage anything is wrong.

>Managers are best off when they
>have a wide range of experience themselves; most good programmers have at
>best a limited background (and I don't mean how many programs they've
>worked on.) 

A wide range of experiences is helpful for both managers and programmers.

>If management can't tell who is a good programmer and who isn't, that's
>right, they ARE technically incompetent. But they're also lousy managers.

That's what we were saying!  To manage programmers, you have to know
something about programming.

Ralph Johnson -- University of Illinois at Urbana-Champaign
From: ewoods@hemel.bull.co.uk (Eoin Woods)
Newsgroups: comp.software-eng
Subject: Re: Complexity metrics: Beyond McCabe.
Date: 23 Nov 92 12:53:48 GMT
Organization: Bull HN UK

paj@uk.co.gec-mrc (Paul Johnson) writes:
>I have had a look at function points.  The trouble is that they behave
>like fractals: the closer you look the more you see.  This strikes me
>as useless.
That is a fair point for inexperienced FP counters - however the basic
point is that FPs are a specification sizing metric, not a complexity
metric.

All bets are off as to the correlation between size and complexity!


Eoin.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Eoin Woods                         | Tel : +44 442 88-4884 (Fax 4570)     |
| Application Services Product Unit  | BVN : (UK) 773-4884                  |
| Bull Information Systems           |                                      |
| Maxted Road                        | E.Woods@uk03.bull.co.uk              |
| Hemel Hempstead, Herts HP2 7DZ, UK | ...!relay1.uu.net!uknet!brno!ewoods  |
Newsgroups: comp.software-eng
From: dominick@protocol.zycad.com (Dom Paniscotti)
Newsgroups: comp.software-eng
Subject: Wanted: Requirements Parser
Date: 20 Nov 1992 16:17:22 -0500
Organization: Protocol, a Division of ZYCAD Corporation
Distribution: world
Reply-To: dominick@protocol.zycad.com
NNTP-Posting-Host: hayaku.protocol.zycad.com
Keywords: requirements


I'm interested in getting some information on the topic of
automated extraction of requirements from text.  If anyone
knows of any papers, programs, YACC grammers, ... etc, please 
let me know.

			Thanks,
				Dom

Newsgroups: comp.software-eng
From: rcd@raven.eklektix.com (Dick Dunn)
Subject: productivity "vs" predictability
Organization: eklektix - Boulder, Colorado
Date: Fri, 20 Nov 1992 06:52:54 GMT

tada@athena.mit.edu (Michael J Zehr) brought up an interesting point out of
the productivity discussion:
>It seems like part of the problem is that software engineers would like
>to increase productivity, but software managers would like to increse
>predictability.  

>Are these opposing goals? Probably somewhat -- predictability generally
>requires more tracking and measuring.

It's possible to get productivity and predictability completely at odds
with one another.  It doesn't happen in the extreme a lot, but there's more
of it than there should be:  *One* way to increase predictability is simply
to add a measure of make-work to the project--which doesn't serve any real
purpose, but makes the variability part of a larger overall number, hence a
smaller fraction.

The trick is to be sure the effort to increase predictability doesn't get
in the way of the work too much.
-- 
Dick Dunn    rcd@raven.eklektix.com   -or-   raven!rcd    Boulder, Colorado
	...Simpler is better.
Newsgroups: comp.software-eng
From: rcd@raven.eklektix.com (Dick Dunn)
Subject: Re: Will we keep ignoring this productivity issue?
Organization: eklektix - Boulder, Colorado
Date: Fri, 20 Nov 1992 07:01:33 GMT

jerbil@ultra.com (Joseph Beckenbach) writes:
>Gerry_Furseth@mindlink.bc.ca (Gerry Furseth) writes:
>> Aphorism: If you can't write a testing plan from your design, the resulting
>>           code will be unreliable.
>
>	Ideally you're refining the test plan while doing the design;...etc...

These guidelines get more complicated if you start writing code first and
derive the design from experience using the code.  In that case, the
evolving code tends to be in the driver's seat--not so much because the
design is subsidiary as because it's lagging behind.  The test plan then
gets to chase both of them.

(It's always a chase anyway, except in the rare cases when you get one of
those delightful projects where the specs hold still through the imple-
mentation.  But code chasing specs is a lot more common, hence [I think]
less unnerving.)
-- 
Dick Dunn    rcd@raven.eklektix.com   -or-   raven!rcd    Boulder, Colorado
	...Simpler is better.
Newsgroups: comp.software-eng
From: travis@eecs.nwu.edu (Travis Marlatte)
Subject: Re: Productivity vs. Complexity
Organization: Rauland-Borg Corporation, Skokie IL
Distribution: na
Date: Mon, 23 Nov 1992 18:11:54 GMT

Marty Leisner says, "Electrical engineers will agree on a good design.
Software engineers generally won't."

Hardware engineers don't agree on a good design any more than software
engineers do. Hardware engineers do agree on the performance of any
given design. You can't argue with measurements of power consumption,
space consumption, etc. But hardware engineers will then spend days
discussing which is more important.

We have similar metrics in software. If we evaluated software by its
executable size, memory requirements, speed, etc, we too would agree
on a good design - and then discuss which is more important.

Lines of code or even complexity are really secondary to the solution.
If software engineers don't agree on a good design, it's because we're
discussing the wrong characteristics.


-- 
Travis Marlatte
travis@eecs.nwu.edu
708-297-0055
Newsgroups: comp.software-eng
From: jerbil@ultra.com (Joseph Beckenbach {Adapter Software Release Engr})
Subject: Re: Will we keep ignoring this productivity issue?
Organization: Ultra Network Technologies
Date: Wed, 18 Nov 92 20:51:30 GMT

	In his article, Gerry_Furseth@mindlink.bc.ca (Gerry Furseth) writes:

> Aphorism: If you can't write a testing plan from your design, the resulting
>           code will be unreliable.

	Ideally you're refining the test plan while doing the design;  start
writing test plan while you're still analyzing the domain and distilling the
specifications.


> Collorary: If you write and execute a testing plan for all your designs, you
>            are not working in software.

	Beg pardon?  Each design has a test plan, otherwise you don't know
whether you've written what you intended to write.  Unless, of course, you
INTEND to write buggy software that doesn't quite solve the problems.

		Joseph Beckenbach
		Test Group, Ultra Network Technologies
-- 
----
Joseph Beckenbach	jerbil@ultra.com	408-922-0600 x246
	(speaking from, but not for, Ultra Network Technologies)

Newsgroups: comp.software-eng
From: mheinric@teal.csn.org (Mark Heinrick)
Subject: Re: SE going offshore?
Organization: Colorado SuperNet, Inc.
X-Newsreader: Tin 1.1 PL4
Date: Mon, 16 Nov 1992 13:46:19 GMT

ejw@siam.ics.uci.edu (Jim Whitehead) writes:
: >His basic argument is that there are plenty of clever, well-trained
: >people in developing countries willing to work for less than their
: >US-based competitors. One example is the HP software shop in Bombay.
: >It will be economically inevitable that this labor-intensive
: >industry will be exported to places where labor is cheap.
: 
: I disagree.  Many software faults can be traced either to faulty
: specifications, or incorrect interpretation of specifications.  For
: the immediate future, the largest market for software will be the
: United States.  This means that either the problem description or
: the specification or both will be expressed in English.  

Jim, we felt that way about a lot of things, like cars and VCR's,
remember??

: Also, since generation/interpretation of specifications is dependent
: on cultural factors, the culture of the programming team could cause
: adverse or unintended effects.

Not necessarily. If someone (or some group) develops a better product,
it is likely to sell. It is the whole quality issue again. Our
offshore competitors will not sit still on this any more than they have
on other issues.

I don't recall anyone "specifying" VisiCalc, OS/360, or Windows NT 
from the outside world. They were determined by visionaries in
their own niches who could do something and do it well. It is
a dangerous fallacy to hope that cultural differences will continue
to protect us for long.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mark Heinrich
Colorado Springs, Colorado
#include <standard_disclaimer.h>
From: nsridharan@faois.intel.com (Sridharan)
Newsgroups: comp.software-eng
Subject: Language competencies & offshore SE
Date: 19 Nov 92 23:58:58 GMT
     <1992Nov17.172139.15122@bnr.uk> <Bxvo8y.Dt5@ddsw1.mcs.com>
     <1992Nov17.170345.29923@mole-end.matawan.nj.us>
Organization: Intel MST
X-Useragent: Nuntius v1.1

In article <1992Nov17.170345.29923@mole-end.matawan.nj.us> ,
mat@mole-end.matawan.nj.us writes:
>Heck, not all people from
>Brooklyn can be understood in Atlanta!

Glad you mentioned Brooklyn.  When I first arrived here from India - took some
time before realizing people spoke English in Brooklyn.

In any case .. someone mentioned the "accent barrier" .. since Brooklynites
understand each other well.. as do muscovites .. and Indians .. remember that
this barrier is a two-way one.  Americans did not invent English  .. many
places around the world have been English-speaking longer than the US.

+ These opinions are my own, but could become yours ++
From: claird@NeoSoft.com (Cameron Laird)
Newsgroups: comp.software-eng
Subject: Making lemonade (was: SE going offshore?)
Date: 18 Nov 92 16:18:20 GMT
Article-I.D.: NeoSoft.Bxx6Mp.C0w
Organization: NeoSoft Communications Services -- (713) 684-5900

In article <BxvF1M.Jqr@cs.uiuc.edu> hasker@cs.uiuc.edu (Rob Hasker) writes:
			.
			.
			.
>How well the person understands English isn't really the whole issue.
>You also need to understand a lot of the culture before you can really
>understand the client, and a good understanding of English doesn't
>imply a complete understanding of culture.  On an exam, I once had
>students draw an entity-relationship diagram which contained "caboose"
>and "motor." Hardly any of the Asian students knew what a caboose was
>(probably not suprisingly), and most thought "motor" meant "motor car"
>(this did surprise me).  I can see such cultural differences causing a
>number of problems.  Of course, formal specifications would probably
>lessen the number of such problems, so we can't assume that all
>software for people in the US has to be written in the West.
Certainly there will be a number of problems.
As you note, "formal specifications would"
change the situation some.  My prediction:
in a quarter of a century, some Harvard scholar
will be explaining to us why such cultural dif-
ferences were a positive *advantage* to India,
Singapore, Indonesia, Lithuania, ...  The suc-
cessful software sites in those places will
have to approach their work in a different way,
and at least some of them will find a different
way that *works*.

One thing that's important to remember about
business:  success does *not* mean answering
all questions; it means answering a few, but
*well*.  Japanese car manufacturers still haven't
proved they can make a better Camaro than GM
(let's say), but who cares?  The big winners are
the ones who change the rules of the game.  This
is, by the way, what I'm trying to say in the
thread on Software Factories.  Mr. Lamaster
(spelling?) is right in all the facts he reports,
but I believe he neglects Mr. McGregor's (spelling?)
point that the nature of programming will change as
more power moves out to end-users.
			.
			.
			.
-- 

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