duncan@ctt.bellcore.com (Scott Duncan) (05/16/91)
In article <1991May15.223719.10256@auto-trol.com> alesha@auto-trol.com (Alec Sharp) writes: > >Why do so many people posting news assume that we are all perfect? >Half the software developers out there are below average. Half the >managers are below average. >Please, let's get away from this elitism in posting and start >addressing the "normal" software development process where many of the >people are below average [...] >Alec Sharp Auto-trol Technology Corporation >(303) 252-2229 12500 North Washington Street, Denver, CO 80241-2404 Alec raises, for me at least, an interesting question. What do we consider to be the "average" in software development? Some posts seem to use "average" as a pejorative term denoting "less than desirable." Hence, "average" managers and programmers are depicted as "bad." I tend to think of groups of people well above "average" or well below, but have a hard time pinning down, for myself, what I consider "average." (I have never worked for a company who thought they didn't try to hire "the best" people. SO whjjere do all the "average" folks end up working? :-)) Taking off from Alec's point, what do people feel the "average" person needs, wants, should expect to have, etc. in a software development environment (the process, tools, whatever)? And what characteristics define "average" in the software field? Speaking only for myself, of course, I am... Scott P. Duncan (duncan@ctt.bellcore.com OR ...!bellcore!ctt!duncan) (Bellcore, 444 Hoes Lane RRC 1H-210, Piscataway, NJ 08854) (908-699-3910 (w) 609-737-2945 (h))
windley@ted.cs.uidaho.edu (Phillip J. Windley) (05/17/91)
In article <1991May16.152429.27870@bellcore.bellcore.com> duncan@ctt.bellcore.com (Scott Duncan) writes:
Alec raises, for me at least, an interesting question. What do we
consider to be the "average" in software development? Some posts seem
to use "average" as a pejorative term denoting "less than desirable."
Hence, "average" managers and programmers are depicted as "bad."
I tend to think of groups of people well above "average" or well below,
but have a hard time pinning down, for myself, what I consider
"average." (I have never worked for a company who thought they didn't
try to hire "the best" people. SO whjjere do all the "average" folks
end up working? :-))
Taking off from Alec's point, what do people feel the "average" person
needs, wants, should expect to have, etc. in a software development
environment (the process, tools, whatever)? And what characteristics
define "average" in the software field?
I can't address the question of what is average, but let's face it, there
is a range of talent out there and not everybody is on top.
This is the real challenge of engineering. Take a look at mary Shaw's
article in IEEE Software (November???, 1990). Engineering disciplines
codify knowledge so that people of modest talent (in the non-pejorative
sense) can do what only virtuoso performers could formerly do. Obviously,
most software enterprises entail significant amounts of virtuoso
performance.
--phil--
--
Phil Windley | windley@cs.uidaho.edu
Assistant Professor | windley@cheetah.cs.uidaho.edu
Department of Computer Science |
University of Idaho | Phone: 208.885.6501
Moscow, ID 83843 | Fax: 208.885.6645orville@weyrich.UUCP (Orville R. Weyrich) (05/17/91)
In article <1991May16.152429.27870@bellcore.bellcore.com> duncan@ctt.bellcore.com (Scott Duncan) writes: >Alec raises, for me at least, an interesting question. What do we consider to >be the "average" in software development? Some posts seem to use "average" as >a pejorative term denoting "less than desirable." Hence, "average" managers >and programmers are depicted as "bad." "Average" implies that there is considerable room for improvement. When I teach and get course evaluations, it is implied that "average" scores are not good enough. >I tend to think of groups of people well above "average" or well below, but >have a hard time pinning down, for myself, what I consider "average." (I >have never worked for a company who thought they didn't try to hire "the best" >people. SO whjjere do all the "average" folks end up working? :-)) The "average programmer" is like the mythical "average housewife", who is 23 years old, has 1.5 children and watches 3.5 hours of soaps a day. There's no such animal. But IF you DID have an objective measure of programming skill, then by definition, half the programmers would be better than the median average and half the programmers would be worse. Not all employers use the same standard for evaluating the desirability of programmers, so it is possible that ALL employers feel that they have the "best" programmers [by their own definitions] that they can find and afford. In some cases, the best programmers may be considered to be those that can stand the straightest when they say "yes, sir!". [sarcasm -- not my definition]. -------------------------------------- ****************************** Orville R. Weyrich, Jr., Ph.D. Certified Systems Professional Internet: orville%weyrich@uunet.uu.net Weyrich Computer Consulting Voice: (602) 391-0821 POB 5782, Scottsdale, AZ 85261 Fax: (602) 391-0023 (Yes! I'm available) -------------------------------------- ******************************
daves@hpopd.pwd.hp.com (Dave Straker) (05/18/91)
>object to useful measurements of code such as branch coverage. I do >object to metrics that are invalid for their intended purpose, >unreliable and full of unrealistic assumptions. Why do people think The trouble with many unrealistic assumptions is that you don't know they're unrealistic until you try them. There is also a matter of degree: some moderately unrealistic assumptions (eg. lines of code) can be used to help make really useful decisions. A danger with the word 'unrealistic' is when it is used to discount things which are not understood. Dave Straker Pinewood Information Systems Division (PWD not PISD) [8-{) HPDESK: David Straker/HP1600/01 Unix: daves@hpopd.pwd.hp.com
kers@hplb.hpl.hp.com (Chris Dollin) (05/22/91)
hlavaty@CRVAX.Sri.Com says:
Noooooooooooo! I totally disagree with this. Quantitative information must
by definition be more valuable and reliable than qualitative information.
Rubbish.
There's nothing in the *definitions* of ``quantative'' and ``qualitative'' that
makes the former more ``valuable'' or ``reliable'' than the latter. Not, at
least, in the definitions I'm familar with.
Whatever numbers make up the quantitative information are indisputable
(assuming the data was gathered correctly) - they become a fact.
There is one bag of coffee-bags on my desk. There are two mugs. This is
indisputable, and a ``fact'' (until I go make coffee). But so what?
What the
numbers *mean* is usually still open to interpretation, but at least two or
more people have a common reference point from which to discuss things.
The same is true of qualitive information.
The
problem with qualitative information is that it is NOT reliable as soon as
more than one person enters the discussion.
I fear you are confusing ``quantative'' with ``objective'', and ``qualitative''
with ``subjective''.
Where qualitative judgements really break down is when two people with
different opinions view the same situation differently. Who's right?
There's of the order of 10e23 atomes of hydrogen in a gramme of same. That's
pretty quantative, right? Do you think that's a big number? Would everyone
agree?
[It isn't, of course. Almost all positive numbers integers are larger than
that.]
The advantage of metrics is that they facilitate a common ground for
discussion between people and organizations. You may disagree with me what
the number mean, but we now have a common reference point.
If we disagree about what they *mean*, how do we have a common reference point?
The real trick to metrics is
really just to start measuring *something*. After trial and error you will
arrive at "things" to track that will work for you and your organization
Ah. You can express this pious hope quantatively, perhaps?
(all of which are peculiar, IMHO).
That particular use of ``peculiar'' comes over as a mild insult in British
English ... :-)
What you are after are "early warnings"
of impending problems that allow you time to fix them up front - before they
are problems.
Very true.
I would argue that someone with a lot of experience that
isn't using metrics consciously is actually using them unconsciously (or
intuitively).
Evidence in support?
[I'm not actually trying to rubbish metrics here, but the arguments quoted
above are far too weak to defend them. Can't we do better?]
--
Regards, Kers. | "You're better off not dreaming of the things to come;
Caravan: | Dreams are always ending far too soon."duncan@ctt.bellcore.com (Scott Duncan) (05/23/91)
There have been a couple posts about this that have gotten into the statistical
meaning of average, median, etc. or at least what these may imply (as in half
the folks above and half below).
There has also been commentary about employer standards for what they want (and
think they have).
What I was trying to get at was that "average" is often a negative term used
to imply those who need to "shape up" in some way. By implication, it seems
to mean "below average."
So my interest in the idea of "average" was to explore what characteristics
people felt distinguish "average," from "below average," from "above average"
in software skill. For example, given many things a person could know about
software development, what would they need to know (or be able to do) to be
"above average?" Then what would qualify them as "average?" Then what would
be "below average?"
I am assuming that even a "below average" person must know _something_ or they
wouldn't even be included in the count!
Speaking only for myself, of course, I am...
Scott P. Duncan (duncan@ctt.bellcore.com OR ...!bellcore!ctt!duncan)
(Bellcore, 444 Hoes Lane RRC 1H-210, Piscataway, NJ 08854)
(908-699-3910 (w) 609-737-2945 (h))