[mdlug] developer psychology [Was: Re: Seeking best practice documentation for "dual-track" development]

[Robert Meier]

Jeff,

  "... But my revelation of the week is that most programmers seem to be
   really insecure about their work. I mean: really, really insecure. ..."
   And yet over and over, I’m gathering stories that point to the fact that
   programmers do not want to write code out in the open. Programmers don’t
   want their peers to see mistakes or failures. They want to work privately,
   in a cave, then spring perfect code on their community, as if no mistakes
   had ever been made. I don’t think it’s hubris so much as fear of
   embarrassment. Rather than think of programming as an inherently social
   activity, most coders seem to treat it as an arena for personal heroics,
   and will do anything to protect that myth. They’re fine with sharing code,
   as long as they present themselves as infallible, it seems. Maybe it’s
   just human nature.
   ... Responses ...
   Ted Lemon says on June 13th, 2008 at 12:22 am:
   Too true. Two observations, though.
   First, sometimes it’s hard to get anyone to look at your code and criticize
   it. And second, it’s not paranoia if someone’s really out to get
   you. Sometimes we fear sharing our code because we have the expectation
   that our fellow geeks will criticize not wisely but too well.
   ...
   Paul Moore says on June 13th, 2008 at 5:08 am:
   ..., many projects expect commits to (generally) pass the test suite
   ..."
     -- http://blog.red-bean.com/sussman/?p=96

The stereotype is I'm sure well-known to any corporate programmers
employed in the last decade.  The "do it right the first time" management
goal has been frequently enforced by immediately releasing the first
code seen, shrinking schedules until no rework can be done,
explicitly prohibitting prototypes, and discouraging finding and
fixing bugs in code seen (as "fixing what aint broke").

Where a friend worked in the recent decade, a managerial announcement
heralded workplace implementation of a defect count found by internal
users in committed code, and a plan to dismiss employees who submitted,
found, or fixed too many (i.e. those unable to prove non-involvement).
The management response to objections advised those objecting to
test thoroughly in isolation, in order to only submit perfect code,
and emphasized that those who submitted code either non-perfect or
that exposed imperfections should quit doing so or find work elsewhere.

Engineers I know, who retired from corporations in the late 80s
and early 90s, disparage such policies as "bean-counting" and
find such incomprehensible, or identify as inexcusable cowardice
the failure of employees to simply quit and go work the next day
for another employer.

Friends I know, who've only been programming within the last decade,
have reported they don't believe it possible to find and fix bugs
within a development team and are convinced that any design effort
beyond a few percent of coding effort is simply waste.

The hopeful news, is that I've seen some recent signs of pressure
to introduce new concepts to corporate programming, specifically
iterative development (once called prototyping) and breadth
of knowledge (once called documentation and reading same).

My observations,
-- 
Bob

  "Overcome space and all we have left is here.
   Overcome time and all we have left is now.
   In the middle of here and now,
   don't you think we'll see each other occasionally?
		-- Jonathan Livingston Seagull by Richard Bach