Who Is Just Not Getting It?

From: Edward Berard (ed_at_toa.com)
Date: 02/20/05 

Date: Sun, 20 Feb 2005 13:00:35 -0600

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/extremeprogramming/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/extremeprogramming/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 Creek Drive         | E-Mail: ed@toa.com
Germantown, Tennessee 38138   | WWW: http://www.toa.com
Loading