Home > Archive > Extreme Programming > February 2005 > Who Is Just Not Getting It?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Who Is Just Not Getting It?
|
|
| Edward Berard 2005-02-20, 3:56 pm |
|
Recently, I was skimming the contents of Yahoo¹s Extreme Programming
Discussion Group (http://groups.yahoo.com/group/extremeprogramming), and
I came across a posting from Kay Pentecost
(http://groups.yahoo.com/group/extre.../message/103842). The
title of Kay's message was "The percent of people who just don't get
it."
The message exhibited an all to common theme among advocates of eXtreme
Programming (XP), i.e., if only the rest of the programming world could
appreciate the true wisdom that they have achieved in the Agile/XP
community.
> From: "Kay Pentecost" <tranzpupy@i...>
> Date: Wed Feb 16, 2005 9:17 pm
> Subject: The percent of people who just don't get it.
>
> Hi, Everybody,
>
> Seems to me that about 90% of the programmers out there are mediocre or
> worse, and are doing nothing to improve.
I wonder:
-> Did Kay mean that:
* "90% of the programmers that she had encountered" were
"mediocre or worse?"
* "90% of all programmers" were "mediocre or worse?"
* "a significant majority of all the programmers that she
had encountered" were "mediocre or worse?"
* or something else entirely?
Unfortunately, Kay is in "good company." Some well known people in the
agile community have made unfounded claims regarding the programming
population in general, e.g.:
"While there is always room for improvement, most software engineers
are reasonably proficient in analysis, programming, testing, and
similar skills."
-- [Highsmith, 2000]
I wondered about Kay's criteria for declaring a programmer "mediocre
or worse." Fortunately, she did document at least some of her ideas:
> Here's what I mean by mediocre and not doing anything to improve:
>
> code is full of duplication
Did Kay gather up a statistically sound, representative sample of
programmers, and examine truly representative samples of each of these
programmers' source code products? Did she define both duplication, and
how to systematically measure it? Did she define what "full of
duplication" meant?
> code is untested
Maybe what she meant was that (at least some of) the programmers she
knew deliberately avoided testing their code. I personally have never
known any such programmers.
> coders are too busy coding to pay attention to quality and sometimes what
> the user wants.
Kay needs to:
-> Define software quality
-> Specify how software quality will be measured
-> Get a basic understanding of software process improvement
> coders are not familiar with the basic books in our industry,
> which include but are not limited to:
> Refactoring
> Pragmatic Programmer
> Extreme Programming (TOS)
> Design Patterns
> Test-Driven Development (Both Kent Beck's and Dave Astel's)
> Code Complete
> This list, or the TDD list, or other lists of this ilk.
As one example, pick up a copy of Beck's first book ([Beck, 2000]), look
up the following items in the index, and then check the page references:
-> Coach, defined
-> Entropy
-> Glossary
-> Load factor
-> Iteration plan, defined
-> Iterations, defined
-> Load factor
-> Manager
-> Metaphors, defined
-> Pair programming, defined
-> Partners
-> Planning game, defined
-> Production phase
-> Programmers, defined
-> Recovery, defined
-> Reestimation, defined
-> Refactoring, defined
-> Tasks, defined
-> Teams, speed of
-> Test cases
-> Test types, automated tests
-> Test types, functional tests
-> Trackers, measuring progress and
-> Unit Tests
(Hopefully, the newer version ([Beck and Andres, 2005]) has fixed these,
and other, defects, without introducing newer defects.)
What do these, and other, defects say about quality and testing? Do
you think a test-driven/test-first/test-infected approach would have
helped in this situation? If so, how? (Do you think that testing
documentation is important?)
What about generic books on: data structures and algorithms, software
psychology, software testing, software quality assurance, software
engineering metrics, software maintenance, software reuse, software
process, software reliability, software usability, software
methodologies, taxonomies, management and team building, metadata,
interoperability, ontologies, ethics and morals, software architecture,
risk and risk management, software safety, software security, and
general software engineering -- to name a few?
(See, also, the "Comp.software-eng FAQ (Part 3): readings" that David
Alex Lamb publishes each month in comp.software-eng.)
Many of the books Kay cites would, at best, fall under the category of
"basic XP books," not "basic books in our industry."
> Okay. That's my opinion, and I'm sticking to it.
>
> Obviously this judgement about programmers does not apply to anyone on this
> list. <grin>
The "this list" Kay is referring to is Yahoo¹s Extreme Programming
Discussion Group.
> How *ever*... while my "training" in school was C, my real experience has
> been in the [dBase, Powerbuilder, Access, Visual Basic] arena, where most of
> the work is GUI-Business Rules-Database stuff. No-Brainer software. <grin>
>
> While I know a little Java (I can read it pretty good, write some, slowly)
> and I've done some work in Smalltalk which helped with my understanding of
> OO, I've never been part of a Java or C++ team so I don't know whether my
> criticism of programmers is true of programmers outside the
> Microsoft-Centric world I lived in before I "discovered" XP and started to
> really learn.
Hopefully, Kay has been able to differentiate between technology and
"agile mythology."
> So maybe life is really different in the Java/Open Source world...
>
> So, my question is, with all due respect for the teams you guys on this list
> are working on, and given the programming worlds you inhabited before XP:
>
> Is there a higher level of non-mediocre programmers in the Java/C++/Open
> Source world? Do more people strive for quality in code and understanding
> and learning?
>
> Or is there really an across-the-board lack of quality, expertise, learning,
> and excellence in the entire programming world?
Imagine a world where:
-> There is no need for John Nosek to conduct any research (e.g.,
[Nosek, 1998]), because, almost 30 years prior to the publication
of his results, we already had research demonstrated the power of
(what he labelled) "collaborative programming." (See, e.g.,
[Fagan, 1974] and [Fagan, 1976].)
-> The major flaws in Laurie Williams's research (e.g., [Williams,
2000]) -- e.g., failure to control variable factors -- are
obvious.
-> People know the difference between software testing and software
quality assurance
-> Programmers, software engineers, and their managers have a healthy
respect for intellectual curiosity.
-> Software practitioners routinely monitor and improve the quality
of the people, processes, and products that comprise their
world.
Such a world exists today.
> If there is, I'd join a Java team in an instant, to have a chance to work
> with people who were constantly trying to learn and excell... even if I had
> to start as a junior programmer...
I suspect that you would find such a situation to be significantly
removed
from your present experiences.
> What do you guys think? Feel free to answer off line if you want to keep
> your info confidential..
BIBLIOGRAPHY
[Beck and Andres, 2005]. K. Beck and C. Andres, Extreme Programming
Explained: Embrace Change, Second Edition, Addison-Wesley, Boston,
Massachusetts, 2005.
[Beck, 2000]. K. Beck, Extreme Programming Explained: Embrace Change,
Addison-Wesley, Reading, Massachusetts, 2000.
[Fagan, 1974]. M.E. Fagan, Design and Code Inspections and Process
Control In the Development of Programs, Technical Report TR 21.572, IBM
System Development Division, Kingston, New York, 1974.
[Fagan, 1976]. M.E. Fagan, ³Design and Code Inspections To Reduce Errors
in Program Development,² IBM Systems Journal, Vol. 15, No. 3, July 1976,
pp. 182 - 211.
[Highsmith, 2000]. J. Highsmith, ³Retiring Lifecycle Dinosaurs,²
Software Testing & Quality Engineering, July/August 2000, pp. 22 _ 28.
[Nosek, 1998]. J.T. Nosek, ³The Case for Collaborative Programming,²
Communications of the ACM, Vol. 41, No. 3, March 1998, pp. 105 - 108.
[Williams, 2000]. L.A. Williams, The Collaborative Software Process,
Ph.D. Dissertation, University of Utah, Salt Lake City, Utah, 2000.
The Percent of People Who Just Don't Get It, Copyright © 2005 Yahoo!
Inc. All rights reserved., Available at
http://groups.yahoo.com/group/extre.../message/103842
Yahoo¹s Extreme Programming Discussion Group, Copyright © 2001 Yahoo!
Inc. Available at http://groups.yahoo.com/group/extremeprogramming
-- Ed
--
Edward V. Berard | Voice: (901) 309-1912
The Object Agency, L.L.C. | Fax: (901) 755-5622
2965 Cane Cr Drive | E-Mail: ed@toa.com
Germantown, Tennessee 38138 | WWW: http://www.toa.com
| |
| Laurent Bossavit 2005-02-20, 8:56 pm |
| Ed,
> I wonder:
> -> Did Kay mean that:
Why don't you ask her ?
Laurent
| |
|
|
|
| Edward Berard wrote:
> Recently, I was skimming the contents of Yahoo¹s Extreme Programming
> Discussion Group (http://groups.yahoo.com/group/extremeprogramming), and
> I came across a posting from Kay Pentecost
> (http://groups.yahoo.com/group/extre.../message/103842). The
> title of Kay's message was "The percent of people who just don't get
> it."
>
> The message exhibited an all to common theme among advocates of eXtreme
> Programming (XP), i.e., if only the rest of the programming world could
> appreciate the true wisdom that they have achieved in the Agile/XP
> community.
>
>
sounds a little generous. I'd say about 99% of "programmers" are
mediocre. Don't know how of them are doing anything about it. Also, see
sturgeon's law.
[color=darkred]
>
> I wonder:
>
> -> Did Kay mean that:
>
> * "90% of the programmers that she had encountered" were
> "mediocre or worse?"
>
> * "90% of all programmers" were "mediocre or worse?"
>
> * "a significant majority of all the programmers that she
> had encountered" were "mediocre or worse?"
>
> * or something else entirely?
>
> Unfortunately, Kay is in "good company." Some well known people in the
> agile community have made unfounded claims regarding the programming
> population in general, e.g.:
>
> "While there is always room for improvement, most software engineers
> are reasonably proficient in analysis, programming, testing, and
> similar skills."
>
> -- [Highsmith, 2000]
>
> I wondered about Kay's criteria for declaring a programmer "mediocre
> or worse." Fortunately, she did document at least some of her ideas:
Hmmmm. My criteria for a mediocre programmer would be any of these:
- Little knowledge of algorithms or data-structures.
- The inability to reason systematically
- The inability to create abstractions
- Little understanding of the performance implications of high-level
statements
- A weak understanding of recursion or pointers [or even of how a
CPU/computer works]
- The inability to design adequate test-cases
Quite often, all of these are aggravated by a lack of experience and
exposure.
<snipped a lot>
The XP crowd can point to a lot of people who are doing completely
undisciplined programming, and can point to a set of techniques that can
(and quite likely will) improve their performance.
However, there is another bunch of people who look at the XP crowd and
think of them as, at best, average programmers, who don't comprehend
what it takes to be good programmers.
I think you can reconcile the conflict expressed in your article if you
consider XP as an introductory set of techniques aimed at improving the
performance of mediocre programmers, and XP programmers as practitioners
who have adopted that set of techniques.
XP, IMO, has many bad practices, and definitely does not capture all
good practices. XP programmers may or may not develop into better
programmers; if they do, they will probably discard some of the XP
practices, and adopt other practices.
| |
| Chris Dollin 2005-02-21, 8:56 am |
| Edward Berard wrote:
>
> Recently, I was skimming the contents of Yahoo¹s Extreme Programming
> Discussion Group (http://groups.yahoo.com/group/extremeprogramming), and
> I came across a posting from Kay Pentecost
> (http://groups.yahoo.com/group/extre.../message/103842). The
> title of Kay's message was "The percent of people who just don't get
> it."
Why on Earth did you post this speculation on Kay's meaning here, rather
than where you read it so that Kay herself could tell you what she meant?
What problem were you trying to solve with this application of the universal
solvent?
--
Chris "electric hedgehog" Dollin
| |
|
|
"CTips" <ctips@bestweb.net> wrote in message
news:111ie96jcumqv1e@corp.supernews.com...
>
> Hmmmm. My criteria for a mediocre programmer
would be any of these:
> - Little knowledge of algorithms or
data-structures.
> - The inability to reason systematically
> - The inability to create abstractions
> - Little understanding of the performance
implications of high-level
> statements
> - A weak understanding of recursion or pointers
[or even of how a
> CPU/computer works]
Sounds like most Java programmers. :-)
Then again, why would a programmer need to know
about pointers? What does
a programmer, using a well-abstracted language,
need to know about recursion
beyond the fact that it can be done? Why is
performance even a consideration
except for the most time-critical software?
Further, these criteria seem to focus on the world
of imperative programming. A
Haskell or ML programmer can create excellent
software without bothering to
agonize over the underlying issues of algorithms
and data structures or even how
a CPU works.
One of the problems with the current state of
software practice might just be our
obsesssion with the machine itself. Java (and C#)
raises the level of abstraction
above the low-level machinery to the JVM. It
eliminates the need for worrying
about pointers, along with all the errors
associated with pointer arithmetic.
On some points we agree. A good programmer, using
whatever language, needs
to be able to think in terms of
levels-of-abstraction and reason in an orderly
way.
However, there are other criteria, too.
We could add,
The ability to see patterns
The ability to decompose a design
into appropriate modules
The ability to know when to
generalize or specialize a design artifact
The ability to know what to eliminate
from a design
The ability to keep a design simple,
understandable, maintainable, and readable
Programming is a human activity. Knuth makes the
point that we need to write software that
is readable by other humans rather than focus so
intensely on programs that are targeted to
the machine. This is one of the better features
of functional langauges.
Most of all, pointers are an artifact of an
old-fashioned style of programming. While
indirection
continues to be important, pointers, as currently
understood in (e.g. the C family of languages)
contemporary programming, are pretty much an
obsolete idea. I do remember the days
of indirect addressing from long ago Assembler
programming. I am happy to be able to ignore
that most of the time in my own programming these
days.
Oh, and I am not a big fan of Java.
Richard Riehle
| |
|
| Richard Riehle wrote:
> CTips wrote:
> would be any of these:
> data-structures.
> implications of high-level
> [or even of how a
>
> Sounds like most Java programmers. :-)
Did you research Java programmers before making that assumption? Did you
survey them? "Most" casually implies >66%. Did you publish your survey in a
peer-reviewed journal? Did it confirm, for each of CTip's points, that >66%
of all Java programmers apply to EACH of them??
> Oh, and I am not a big fan of Java.
Ah, so you admit your fan-atacism has tempered your judgement! Your entire
post is invalid!!
--
Phlip
http://industrialxp.org/community/b...tUserInterfaces
Boyce, Mary
A reader in Manichaean : Middle-Persian and Parthian
texts with notes by Mary Boyce (1975)
In: Acta Iranica : 3. sér., Textes et mémoires ; v.2
Leiden: E. J. Brill, 1975, 196 p.
Abstract: Texts in Pahlavi or Parthian (romanized)
"Parthian Writings and Literature" (1983)
In: Yarshater, Ehsan (ed.), The Cambridge History of Iran.
The Seleucid, Parthian and Sasanian Periods, vol. 3, part 2
Cambridge: Cambridge University Press, 1983, p. 1151-1165.
"The Sedentary Arsacids" (1994)
Iranica Antiqua, 1994, vol. 29, p. 242-251.
Boyce, Mary & Zwanziger, Ronald
A word-list of Manichaean Middle Persian and Parthian
by Mary Boyce ; with a reverse index by Ronald Zwanziger (1977)
In: Acta Iranica : 3. sér., Textes et mémoires ; v. 2: Suppl Acta Iranica
9a
Leiden: E. J. Brill, 1977, 172 p.
Abstract: Reverse index to A reader in Manichaean
Middle Persian and Parthian
Brace, Charles L.
The Races of the Old World : A Manual of Ethnology (1863)
New York: Charles Scribner's Sons, 1863, 540 p.
Bradford, Alfred S.
With arrow, sword, and spear : a history of warfare in the ancient world
(2001)
Westport, Conn.: Praeger, 2001, xviii+312 p.
Abstract: illustrated by Pamela M. Bradford. Most studies of ancient
warfare focus only on the Grs and the Romans, but this sweeping study
covers the whole of the ancient world from Greece and Rome to the Near East,
then eastward to Parthia, India, and China. Bradford transports the reader
into the midst of ancient battles behind such great leaders as Thutmose III,
Ashurbanipal, Alexander, Hannibal, Caesar, and the First Emperor of China.
He details the rise and fall of empires, the role of leadership, and the
development of tactics and strategy. One sees the clash of peoples: nomads
against agricultural societies, infantry against cavalry, as well as the
greatest technological change in history--the combination of the composite
bow and the chariot. [Publisher]
Brady, Charles A.
Report to the royal academy of Parthia for transmission to
Phraataces, king of kings (1958)
Buffalo: 1958, 1 p.
Abstract: Christmas poem from the Brady family.
White paper printed in black; illustrated in green, blue, red, and
gold.
Braund, David
"The Caspian Gates in Roman-Persian relations in ancient Transcaucasia"
(2000)
Archäologische Mitteilungen aus Iran, 2000, vol. 32, p. 37-41.
Breccia, Evaristo
"Mitridate I il Grande, di Partia" (1905)
Klio, 1905, vol. 5, p. 39-54.
Brentjes, Burchard
"'Parthian' Monuments in Transcaucasia and Central Asia" (1988)
Bulletin of the Asia Institute, 1988, tome/ser. New, vol. 2
Abstract: In addition to structures at Nisa (Turkmenistan), temples at the
sites of Mansur-depe (Turkmenistan) and Dedoplis Mindori (Georgia) are
considered as Parthian. [C.A. Bromberg]
"Incised Bones and a Ceremonial Belt: Finds from Kurgan-Tepe and
Tillia-Tepe" (1989)
Bulletin of the Asia Institute, 1989, tome/ser. New, vol. 3
Abstract: A ceremonial belt found at Tillia-tepe is compared to
Parthian-period belts. The author discusses belts from Mathura, Hatra, and
Mzcheta (Georgia). [C.A. Bromberg]
Steppenreiter und Handelsherren : die Kunst der Partherzeit in Vorderasien
(1990)
Leipzig: E. A. Seemann, 1990
Abstract: Numerous illustrations in the text and 37 fig., partly in color,
on art print boards. Time line. Literature. Register. Excellent overview of
Parthian art in the core area and the adjacent zones of influence (Syria,
Armenia, Georgia, etc.).
Brett, Agnes Baldwin
Catalogue of Gr coins / by Agnes Baldwin Brett, honorary curator of
classical coins, Museum of Fine Arts, Boston ; with a new introd. by Mary B.
Comstock and Cornelius C. Vermeule, Jr (1955)
New York: Attic Books, 1974
Abstract: Unchanged reprint of the 1955 ed. published by the museum.
Parthian coins are catalog numbers 2209-2231, 2344; Elymais 2232; Persis
2342-2343; Bacrtia 2233-2244, all with plates. Includes bibliographies,
concordances and indexes. Dobbins (1975) provides plates of Parthian coins,
catalog nos. 2218-2223.
Briant, Pierre
"Les débuts de la domination Macédonienne en Iran" (1999)
In: Boucharlat, Rémy (ed.), Empires Perses d'Alexandre aux Sassanides
Dossiers d'Archeologie, 1999, no. 243, p. 2-5.
Brindley, James C.
"The organization of the Parthian bronze coinage" (1976)
In: Le Rider, Georges & Cahn, Herbert A., Proceedings of the 8th
International Congress of Numismatics, New York-Washington, September 1973
Paris and Basel: Association internationale des Numismates professionnels,
1976, p. 31-38.
Abstract: Remarks presented at the Numismatic Congress in 1973. "The
denominations and the distribution among various mints down to the end of
the reign of Gotarzes II (A.D. 51) are discussed rather summarily."
[Mørkholm, "Greece to India", 1979]
| |
| Robert C. Martin 2005-02-22, 3:58 pm |
| On Sun, 20 Feb 2005 13:01:39 -0600, Edward Berard <ed@toa.com> wrote:
>I wonder:
>
> -> Did Kay mean that:
>
> * "90% of the programmers that she had encountered" were
> "mediocre or worse?"
>
> * "90% of all programmers" were "mediocre or worse?"
>
> * "a significant majority of all the programmers that she
> had encountered" were "mediocre or worse?"
>
> * or something else entirely?
I think Kay was simply talking about Fred Brooks' old observation that
there is a huge range of programming ability. Some programmers are
ten times as productive as others. Those 10X programmers are 10 times
as rare as the norm.
I think both Kay and Brooks used the number 10 symbolically, not as an
actual measurement. Indeed I'm not sure that Brooks used the number
10. He may have just said "many". But the point is the same.
To paraphrase: "There are too many mediocre programmers."
-----
Robert C. Martin (Uncle Bob) | email: unclebob@objectmentor.com
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716
"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo
| |
| Edward Berard 2005-02-22, 8:57 pm |
| In article <05lm11l0tpt2pq3igh2aa2nnr1k9k5d1c3@4ax.com>, Robert C.
Martin <unclebob@objectmentor.com> wrote:
> I think Kay was simply talking about Fred Brooks' old observation that
> there is a huge range of programming ability. Some programmers are
> ten times as productive as others. Those 10X programmers are 10 times
> as rare as the norm.
>
> I think both Kay and Brooks used the number 10 symbolically, not as an
> actual measurement. Indeed I'm not sure that Brooks used the number
> 10. He may have just said "many". But the point is the same.
>
> To paraphrase: "There are too many mediocre programmers."
Please allow me to restrict my comments to the paraphrase:
"There are too many mediocre programmers."
1. Dictionary (e.g., Dictionary.com) definitions for "mediocre"
include:
a. moderate to inferior in quality
b. of no exceptional quality or ability
c. poor to middling in quality
d. ordinary
2. "Quality" is one of the words most commonly misused by software
practitioners. Beyond alluding to a direct relationship between
the number of defects in a piece of software, and the "quality of
that software," many software practitioners seldom define
"quality" -- much less measure it.
There is also the frequent blurring among "the quality of people,"
"the quality of processes," and "the quality of products."
It is this problem of understanding "quality," and all of its
associated connotations, that makes a determination of "mediocre
programmers" all the more difficult.
3. "too many," within the context of the paraphrase, could mean
anywhere from 1 to some relatively large number.
a. For example, in the case of intensely critical applications,
even one mediocre programmer might be considered "too many."
b. As another example, a "perfectionist" might become exasperated
if a simple majority of the programmers that s/he encountered
did not exhibit some minimum acceptable level of quality.
4. Then there are the contentious issues of who gets to:
a. define quality
b. define how quality will be measured
c. set the threshold levels of quality, e.g., set the minimum
acceptable levels of quality for "non-mediocre" programmers.
-- Ed
--
Edward V. Berard | Voice: (901) 309-1912
The Object Agency, L.L.C. | Fax: (901) 755-5622
2965 Cane Cr Drive | E-Mail: ed@toa.com
Germantown, Tennessee 38138 | WWW: http://www.toa.com
| |
|
| Edward Berard wrote:
> Please allow me to restrict my comments to the paraphrase:
>
> "There are too many mediocre programmers."
You snipped the part where Kay said, "That's my opinion". You then
behaved as if she stated absolutes, not opinions.
Her post was a long apologia for not knowing the answer to this
question:
"Is there a higher level of non-mediocre programmers in the
Java/C++/Open Source world? Do more people strive for quality in code
and understanding and learning?"
You are not helping answer (despite we all agree you personally
qualify). You are, instead, pushing the goal posts impossibly far away
by demanding more strict use of definitions than humanly possible.
The answer to Kay's question: The grass is always greener on the other
side of the fence. Some C++, even the core code of huge companies, has
quality so low that no definition is needed. However, the non-VB world,
seen from the perspective of VB, appears to contain only stand-outs
that achieve recognition. Linux, Ruby, DOOM, etc.
> 2. "Quality" is one of the words most commonly misused by software
> practitioners. Beyond alluding to a direct relationship between
> the number of defects in a piece of software, and the "quality of
> that software," many software practitioners seldom define
> "quality" -- much less measure it.
>
> There is also the frequent blurring among "the quality of people,"
> "the quality of processes," and "the quality of products."
>
> It is this problem of understanding "quality," and all of its
> associated connotations, that makes a determination of "mediocre
> programmers" all the more difficult.
If Kay had said, "I have proven that {XP|VB|Dell|Polyphonic Spree} is
superior due to quality", then such an investigation would be
reasonable. She asked about relative rankings, not absolutes.
The quality of your post is very low, because you pretended you thought
she meant something that she didn't.
--
Phlip
"Et tu Piglet? Then (oh bother) fall, Pooh!"
| |
|
|
"Phlip" <phlip_cpp@yahoo.com> wrote in message
news:kCFSd.11209$hU7.476@newssvr33.news.prodigy.com...
> Richard Riehle wrote:
>
pointers[color=darkred]
>
> Did you research Java programmers before making
that assumption? Did you
> survey them? "Most" casually implies >66%. Did
you publish your survey in a
> peer-reviewed journal? Did it confirm, for each
of CTip's points, that >66%
> of all Java programmers apply to EACH of them??
Ah, Phlip, did you not notice the smiley I
suffixed to my comment? Did you
not notice the nice things I said about Java in
the rest of my post?
>
> Ah, so you admit your fan-atacism has tempered
your judgement! Your entire
> post is invalid!!
>
I said, "I am not a big fan of Java," to
neutralizie the nice things
I said about the language. That comment was
intended to suggest that
I had nice things to say about Java even though it
was not my preferred language.
That being said, Java was not delivered from
on-high by some deity. As
with other languages, even Ada and Eiffel, it has
its flaws. It will do us
all a bit of good not to engage in religiofication
of programming languages
and to recognize that we can find good things to
say about all of them, and
bad things to say about all of them.
For certain classes of problems, Java is perfectly
appropriate. As new languages
come along, such as C#, the designers of those new
languages will have learned
a thing or two from the good, the bad, and the
ugly in the predecessor languages.
Ideally, a language will be designed with
sufficient resilience that it can evolve as
new ideas emerge, or as improvements are required.
Can Java evolve beyond
its current limitations. Of course! Even COBOL
and Fortran continue to evolve.
The current Fortran standard is quite respectable,
even though I can still find
some things about it I would like to see done
differently.
I prefer to use a language that includes
genericity. So far, Java does not have
it. On the other hand, interfaces are a splendid
feature of the language, and the
new Ada standard, continuing to evolve, will adopt
that idea from Java.
In any case, when I say, in response to the
comment that programmers are no
good unless they understand pointers and low-level
machine features, "Sounds
like most Java programmers," you should take that
as a compliment. I was, in
my own obscure way, trying to point out how
ridiculous it is too assume that
good programmers need to understand pointers. I'm
sure you would agree
that good Java programmers can get along just fine
without doing pointer
arithmetic.
After reading this, I hope you are able to
successfully untangle your shorts and
move about with greater agility. That knot you
tied in them must have hurt
something awful. :-)
Richard Riehle
| |
|
| Richard Riehle wrote:
> Ah, Phlip, did you not notice the smiley I
> suffixed to my comment? Did you
> not notice the nice things I said about Java in
> the rest of my post?
Oops. Sorry. Was I supposed to /read/ your post before replying to it?
That seems to be out of fashion...
Oh, here: (-:
--
Phlip
| |
|
| No problem Phlip.
I should have been a little less coy in the way I
phrased my earlier remarks.
Peace.
Richard Riehle
========================================
==========
===
"Phlip" <phlip2005@gmail.com> wrote in message
news:1109132077.928440.216270@z14g2000cwz.googlegroups.com...
> Richard Riehle wrote:
>
in[color=darkred]
>
> Oops. Sorry. Was I supposed to /read/ your post
before replying to it?
> That seems to be out of fashion...
>
> Oh, here: (-:
>
> --
> Phlip
>
| |
| Robert C. Martin 2005-02-23, 3:57 am |
| On Tue, 22 Feb 2005 13:58:06 -0600, Edward Berard <ed@toa.com> wrote:
>In article <05lm11l0tpt2pq3igh2aa2nnr1k9k5d1c3@4ax.com>, Robert C.
>Martin <unclebob@objectmentor.com> wrote:
>
>Please allow me to restrict my comments to the paraphrase:
>
> "There are too many mediocre programmers."
>
> 1. Dictionary (e.g., Dictionary.com) definitions for "mediocre"
> include:
>
> a. moderate to inferior in quality
>
> b. of no exceptional quality or ability
>
> c. poor to middling in quality
>
> d. ordinary
>
> 2. "Quality" is one of the words most commonly misused by software
> practitioners. Beyond alluding to a direct relationship between
> the number of defects in a piece of software, and the "quality of
> that software," many software practitioners seldom define
> "quality" -- much less measure it.
>
> There is also the frequent blurring among "the quality of people,"
> "the quality of processes," and "the quality of products."
>
> It is this problem of understanding "quality," and all of its
> associated connotations, that makes a determination of "mediocre
> programmers" all the more difficult.
>
> 3. "too many," within the context of the paraphrase, could mean
> anywhere from 1 to some relatively large number.
>
> a. For example, in the case of intensely critical applications,
> even one mediocre programmer might be considered "too many."
>
> b. As another example, a "perfectionist" might become exasperated
> if a simple majority of the programmers that s/he encountered
> did not exhibit some minimum acceptable level of quality.
>
> 4. Then there are the contentious issues of who gets to:
>
> a. define quality
>
> b. define how quality will be measured
>
> c. set the threshold levels of quality, e.g., set the minimum
> acceptable levels of quality for "non-mediocre" programmers.
>
Agreed, agreed. And yet, there are too many mediocre programmers.
-----
Robert C. Martin (Uncle Bob) | email: unclebob@objectmentor.com
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716
"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo
| |
|
| Richard Riehle wrote:
> I should have been a little less coy in the way I
> phrased my earlier remarks.
Dude, the founder of news:comp.object was scanning the XP mailing list,
looking for an example of the hyperbole he knew he'd find there, and Kay
obliged him. Can I resist getting in on the fun, right down to the
bibliography?
Yes, folks, 50% of all programmers are below average! ... or is it
"median":?
--
Phlip
http://industrialxp.org/community/b...tUserInterfaces
| |
| Peter K. 2005-02-23, 3:58 pm |
| ] Yes, folks, 50% of all programmers are below average! ... or is it
] "median":?
Ten people take a test. Nine get 10 / 10 and one gets 1 /10.
90% of the people taking the test scored above the average (mean,
median, mode).
:-)
Ciao,
Peter K.
| |
| Edward Berard 2005-02-23, 3:58 pm |
| In article <5m3o11l6shh0qbs0iqhlvdvb2cm5bsrhtg@4ax.com>, Robert C.
Martin <unclebob@objectmentor.com> wrote:
> Agreed, agreed. And yet, there are too many mediocre programmers.
Just out of curiosity: Suppose that you had to prove "in court" that
"there are too many mediocre programmers." How would you do it?
I will allow that there may very well be "too many mediocre
programmers." So, I am not necessarily disagreeing with the
premise.
-- Ed
--
Edward V. Berard | Voice: (901) 309-1912
The Object Agency, L.L.C. | Fax: (901) 755-5622
2965 Cane Cr Drive | E-Mail: ed@toa.com
Germantown, Tennessee 38138 | WWW: http://www.toa.com
| |
| Goran Sliskovic 2005-02-23, 3:58 pm |
|
"Phlip" <phlip_cpp@yahoo.com> wrote in message
news:CUVSd.11427$hU7.4981@newssvr33.news.prodigy.com...
> Richard Riehle wrote:
....
>
> Yes, folks, 50% of all programmers are below average! ... or is it
> "median":?
>
....
50% are below median by definition. Mean == median for symmetric
distributions. I'd expect programmers skill distribution to be symmetric
(normal aka gaussian).
Disclaimer: it's been long time since I took statistics classes :)
Regards,
Goran
| |
| Otis Bricker 2005-02-23, 3:58 pm |
| "Goran Sliskovic" <gsliskov@yahoo.com> wrote in news:cvibeo$aiu$1
@ls219.htnet.hr:
>
> "Phlip" <phlip_cpp@yahoo.com> wrote in message
> news:CUVSd.11427$hU7.4981@newssvr33.news.prodigy.com...
> ...
> ...
>
> 50% are below median by definition. Mean == median for symmetric
> distributions. I'd expect programmers skill distribution to be symmetric
> (normal aka gaussian).
>
Why would you expect that? If, for the set of all individuals,
'programming' skills could be measured they might fit such a curve. But
then the world steps in and truncates the bottom (pick a value)% from the
set of programmers since they are too 'unskilled' to make a living at it.
So you can find incredibly good programmers, but it is a challange to find
incredibly bad(thinking of that computerphobic grandmother of mine) ones.
Otis
| |
| Robert C. Martin 2005-02-23, 8:57 pm |
| On Wed, 23 Feb 2005 12:51:16 -0600, Otis Bricker
<obricker@my-dejanews.com> wrote:
>So you can find incredibly good programmers, but it is a challange to find
>incredibly bad(thinking of that computerphobic grandmother of mine) ones.
Would that it were so. Unfortunately it can be very easy to hide in
large IT organizations. I have seem teams go on for years with
"developers" who never manage to deliver a single working line of
code.
-----
Robert C. Martin (Uncle Bob) | email: unclebob@objectmentor.com
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716
"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo
| |
| Andrew McDonagh 2005-02-23, 8:57 pm |
| Reply-To: news@us.com
NNTP-Posting-Host: i-83-67-4-97.freedom2surf.net
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.freedom2surf.net 1109198149 4256 83.67.4.97 (23 Feb 2005 22:35:49 GMT)
X-Complaints-To: abuse@freedom2surf.net
NNTP-Posting-Date: Wed, 23 Feb 2005 22:35:49 +0000 (UTC)
To: u.n.c.l.e.b.o.b@objectmentor.com
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
In-Reply-To: <r80q11hl8n91rblik14j35uj7dlqrdf8nb@4ax.com>
Xref: number1.nntp.dca.giganews.com comp.software-eng:85118 comp.software.extreme-programming:32938
Robert C. Martin wrote:
> On Wed, 23 Feb 2005 12:51:16 -0600, Otis Bricker
> <obricker@my-dejanews.com> wrote:
>
>
>
>
> Would that it were so. Unfortunately it can be very easy to hide in
> large IT organizations. I have seem teams go on for years with
> "developers" who never manage to deliver a single working line of
> code.
>
> -----
> Robert C. Martin (Uncle Bob) | email: unclebob@objectmentor.com
> Object Mentor Inc. | blog: www.butunclebob.com
> The Agile Transition Experts | web: www.objectmentor.com
> 800-338-6716
>
>
> "The aim of science is not to open the door to infinite wisdom,
> but to set a limit to infinite error."
> -- Bertolt Brecht, Life of Galileo
I've seen the situation where these type of 'developers' think they are
hidden, yet everyone, including the management knows about them.
However, because the management are so resistant to deal with the
situation properly, they resolve it by moving the 'developers' into
other positions usually some form of project leadership or other less
valuable projects.
| |
| Robert C. Martin 2005-02-23, 8:57 pm |
| On Wed, 23 Feb 2005 09:57:12 -0600, Edward Berard <ed@toa.com> wrote:
>In article <5m3o11l6shh0qbs0iqhlvdvb2cm5bsrhtg@4ax.com>, Robert C.
>Martin <unclebob@objectmentor.com> wrote:
>
>
>Just out of curiosity: Suppose that you had to prove "in court" that
>"there are too many mediocre programmers." How would you do it?
By definition. *Any* mediocre programmers is too many.
-----
Robert C. Martin (Uncle Bob) | email: unclebob@objectmentor.com
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716
"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo
| |
|
| Robert C. Martin wrote:
> Edward Berard wrote:
>
>
> By definition. *Any* mediocre programmers is too many.
Suppose you had to prove in court that *I* was mediocre.
(Remember, if ordinary means mediocre, then "extraordinary" must
mean...)
--
Phlip
| |
| Laurent Bossavit 2005-02-23, 8:57 pm |
| Phlip,
> Suppose you had to prove in court that *I* was mediocre.
Can't sing. Can't dance. Can program and draw a little. :)
Laurent
| |
| Otis Bricker 2005-02-24, 3:57 am |
| Message-ID: <Xns9606CA55A457obrickermydejanewsco@216.196.97.136>
User-Agent: Xnews/5.04.25
Date: Wed, 23 Feb 2005 18:53:25 -0600
Lines: 31
NNTP-Posting-Host: 68.80.237.8
X-Trace: sv3- OcRsOjC5WMO5rdVtMXIdRDCQxo9+7BUma4j3ba6w
J+tySnd9pW7Fu3GTFu0TufnvGSLl8dFESfim7Pu!
puWp0uvcvtiPbCZBybcCFbPV9FIW4DFX00vKrswR
z860XbHTfTby13Bxza+ZSV6uEmo7GA+10tnl!bPL
P
X-Complaints-To: abuse@comcast.net
X-DMCA-Complaints-To: dmca@comcast.net
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.31
Xref: number1.nntp.dca.giganews.com comp.software-eng:85120 comp.software.extreme-programming:32943
Robert C. Martin <unclebob@objectmentor.com> wrote in
news:r80q11hl8n91rblik14j35uj7dlqrdf8nb@
4ax.com:
> On Wed, 23 Feb 2005 12:51:16 -0600, Otis Bricker
><obricker@my-dejanews.com> wrote:
>
>
> Would that it were so. Unfortunately it can be very easy to hide in
> large IT organizations. I have seem teams go on for years with
> "developers" who never manage to deliver a single working line of
> code.
>
Maybe I have been fortunate, but I haven't run into anyone that was as bad
as I can imagine someone being. There are some folks that simple could not
pass a job interview as a programmer. Just as I might have trouble being a
Graphic Designer or English Teacher. Different sets of skill. Even the
worst programmers I've met could do some simple tasks. I, on the other hand
would be hard pressed to explain anything out of "Romeo and Juliet".
While it isn't proper statistically, this might explain why some folks feel
that there are so many mediocre programmers. Assume skill was distributed
normally and you truncate the bottom third of the curve. If you look at the
remainder and the number above and below its halfway point, you would have
the vast majority in the bottom.
Otis Bricker
| |
|
| Otis Bricker wrote:
> Maybe I have been fortunate, but I haven't run into anyone that was
as bad
> as I can imagine someone being. There are some folks that simple
could not
> pass a job interview as a programmer. Just as I might have trouble
being a
> Graphic Designer or English Teacher. Different sets of skill. Even
the
> worst programmers I've met could do some simple tasks. I, on the
other hand
> would be hard pressed to explain anything out of "Romeo and Juliet".
Per Kay's post (and oblivious to correct statistical procedure), how
much VB have you experienced?
--
Phlip
| |
| Johnny Cache 2005-02-24, 3:57 am |
| Ah, Brooks. But finish the thought . . . .
As I recall, Brooks does not celebrate the skills of the would be
project manager who claims that with ten crack programmer's he could
manage to do some really impressive thing. This, Brooks explains is no
big deal.
The real master, in his essay, is the PM who can get great work out of a
team of what I refer to, with apologies to the French, as our
programmers ordinaire. With the right technical and administrative
leadership, these folks help us deliver what our clients need.
Anyway, that's what I think.
JC
Robert C. Martin wrote:
> On Sun, 20 Feb 2005 13:01:39 -0600, Edward Berard <ed@toa.com> wrote:
>
>
>
>
> I think Kay was simply talking about Fred Brooks' old observation that
> there is a huge range of programming ability. Some programmers are
> ten times as productive as others. Those 10X programmers are 10 times
> as rare as the norm.
>
> I think both Kay and Brooks used the number 10 symbolically, not as an
> actual measurement. Indeed I'm not sure that Brooks used the number
> 10. He may have just said "many". But the point is the same.
>
> To paraphrase: "There are too many mediocre programmers."
>
>
> -----
> Robert C. Martin (Uncle Bob) | email: unclebob@objectmentor.com
> Object Mentor Inc. | blog: www.butunclebob.com
> The Agile Transition Experts | web: www.objectmentor.com
> 800-338-6716
>
>
> "The aim of science is not to open the door to infinite wisdom,
> but to set a limit to infinite error."
> -- Bertolt Brecht, Life of Galileo
| |
| Otis Bricker 2005-02-24, 3:57 am |
| "Phlip" <phlip2005@gmail.com> wrote in news:1109208098.953442.321410
@l41g2000cwc.googlegroups.com:
> Otis Bricker wrote:
>
> as bad
> could not
> being a
> the
> other hand
>
> Per Kay's post (and oblivious to correct statistical procedure), how
> much VB have you experienced?
>
None up close and personal. One of my co-workers is a clever chap who
builds all our test utilities with it.
But I have heard stories.
Otis
| |
| Isaac Gouy 2005-02-24, 3:57 am |
|
Johnny Cache wrote:
> Ah, Brooks. But finish the thought . . . .
>
> As I recall, Brooks does not celebrate the skills of the would be
> project manager who claims that with ten crack programmer's he could
> manage to do some really impressive thing. This, Brooks explains is
no
> big deal.
>
> The real master, in his essay, is the PM who can get great work out
of a
> team of what I refer to, with apologies to the French, as our
> programmers ordinaire. With the right technical and administrative
> leadership, these folks help us deliver what our clients need.
Well said!
| |
|
| Laurent Bossavit wrote:
> Phlip,
>
>
> Can't sing. Can't dance. Can program and draw a little. :)
Uh, actually I have adequate pitch, nearly infinite sustain, perfect timing,
amazing lyrical recall, unearthly dynamic range, and adequate moves.
I wanted to limit the proof to the programming & software engineering part.
--
Phlip
http://industrialxp.org/community/b...tUserInterfaces
| |
| Bradley K. Sherman 2005-02-24, 8:56 am |
| In article <Xns9606CA55A457obrickermydejanewsco@216.196.97.136>,
Otis Bricker <obricker@my-dejanews.com> wrote:
>
>While it isn't proper statistically, this might explain why some folks feel
>that there are so many mediocre programmers. Assume skill was distributed
>normally and you truncate the bottom third of the curve. If you look at the
>remainder and the number above and below its halfway point, you would have
>the vast majority in the bottom.
>
Same with Doctors, Lawyers and Roofers.
--bks
| |
| Otis Bricker 2005-02-24, 3:57 pm |
| bks@panix.com (Bradley K. Sherman) wrote in
news:cvkhb9$kah$1@reader2.panix.com:
> In article <Xns9606CA55A457obrickermydejanewsco@216.196.97.136>,
> Otis Bricker <obricker@my-dejanews.com> wrote:
>
> Same with Doctors, Lawyers and Roofers.
>
> --bks
>
Maybe. Since this is all speculation, I'll do some more.
Lawyers and Roofers probably follow the same trend. Since there is little
barrier to entry. Doctors might not. While I would not argue that there
are no mediocre Medical Doctors, the entry barriers to becoming one
(limited number of medical schools, Board reviews, insurance
requirements) probably cut the curve at a much higher spot. Maybe only
the top 1/3 of the curve. This is a SOTP(Seat Of The Pants) estimate. So
while it still produces a majority of the remainder in the bottom 1/2 of
the distribution, it would not have the same overwhelming difference in
numbers.
But it is true that I am claiming that because of population selection,
the majority of any profession will be below the 1/2 way point in skill.
Now this also needs to have top end adjustments made. Skill/Talent
overlap may well cut off a large junk of the best Roofers and move them
into the higher paying fields of Carpentry or General Contracting.
But I was just trying to point out that there was no real reason to
expect a symmetric distribution of skills WITHIN the profession.
Sorry, This obviously has little to do with Engineering or XP and I will
stop dragging it out. Unless I cannot help myself.
--
Otis
| |
| Robert C. Martin 2005-02-25, 3:57 am |
| On 23 Feb 2005 14:50:35 -0800, "Phlip" <phlip2005@gmail.com> wrote:
>Robert C. Martin wrote:
>
>
>Suppose you had to prove in court that *I* was mediocre.
I don't think I could find enough people who were worse than you to
make the case.
-----
Robert C. Martin (Uncle Bob) | email: unclebob@objectmentor.com
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716
"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo
| |
| Robert C. Martin 2005-02-25, 3:57 am |
| On Thu, 24 Feb 2005 02:16:27 GMT, Johnny Cache <johnny.cache@att.not>
wrote:
>The real master, in his essay, is the PM who can get great work out of a
>team of what I refer to, with apologies to the French, as our
>programmers ordinaire. With the right technical and administrative
>leadership, these folks help us deliver what our clients need.
Brooks' model (citing Harlan Mills) has that PM being *the* chief
programmer who writes nearly all the code in the system. The members
of his team do lesser tasks that support his incredible programming
talent.
-----
Robert C. Martin (Uncle Bob) | email: unclebob@objectmentor.com
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716
"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo
| |
| Robert C. Martin 2005-02-25, 3:57 am |
| On Thu, 24 Feb 2005 02:16:27 GMT, Johnny Cache <johnny.cache@att.not>
wrote:
>The real master, in his essay, is the PM who can get great work out of a
>team of what I refer to, with apologies to the French, as our
>programmers ordinaire. With the right technical and administrative
>leadership, these folks help us deliver what our clients need.
Projects manned by expert programmers would die a horrible death if
not for the able efforts of a good PM. However, no PM on the planet
can make steak out of hash. If the programmers are mediocre, the
product will be too. The best the PM can hope for is to avoid a
disaster and achieve a mediocre outcome.
-----
Robert C. Martin (Uncle Bob) | email: unclebob@objectmentor.com
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716
"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo
| |
| Isaac Gouy 2005-02-25, 3:57 am |
|
Robert C. Martin wrote:
> On Thu, 24 Feb 2005 02:16:27 GMT, Johnny Cache <johnny.cache@att.not>
> wrote:
>
of a[color=darkred]
>
> Projects manned by expert programmers would die a horrible death if
> not for the able efforts of a good PM. However, no PM on the planet
> can make steak out of hash. If the programmers are mediocre, the
> product will be too. The best the PM can hope for is to avoid a
> disaster and achieve a mediocre outcome.
There's a wealth of talent between expert and mediocre.
| |
|
| Robert C. Martin wrote:
>
> I don't think I could find enough people who were worse than you to
> make the case.
I'm still wondering why I have an acknowledgement in /AD:PPP/. I would have
told you to pull the margins in 15 points. But (honestly) thanks anyway.
--
Phlip
http://industrialxp.org/community/b...tUserInterfaces
|
|
|
|
|