RE: "One person per product"

I agree with most, but not all...

Pretty sure Tom Demarco said the same thing (maybe he said 20 minutes).  I
think this length of time depends on the difficulty of the project.  The
mindframe to get to to effectively modify packaged software would be A LOT
longer than the time to get back to modifying a menu, for example.

Demarco also sited an IBM study that the ideal environment is an office, not
a cube.  With 100 sq ft of space and 64 sq ft of desk space.  I don't quite
have that here, but have used that in the past and it IS the best approach,
IMV.


I don't necessarily agree with the one-man approach however.  I've used
(what they now call) Extreme Programming
(http://computerworld.com/nlt/0%2C3590%2CNAV47_STO66192_NLTAPP%2C00.html).
It works...

The article says "Pair programming is perhaps the most controversial aspect
of XP."  And add:  "But pair programming won't work for every company or
developer."  It ends with the comment "But right now, there isn't enough
evidence yet that XP is a breakthrough that all teams should embrace."


Here's the evidence:

About 15 years ago I became head of a small shop, after 6 months supervisory
experience.  If I'd known what I was gonna be getting into, I never would
have attempted it.  First major event was we lost our Business Analyst
(transferred to parent org) and ALL of our PC expertise with him.  I knew a
fair bit about the systems, but you can't learn much about EVERY aspect
about the code in 3 years, and my job duties were primarily restricted to
certain sub-systems and projects..  Not learning all the systems.  Even
more, in that length of time, you can't begin to learn both the fact that,
and how, each line of code effects the way the company does business.  (Nor
IMHO with < 10 years of experience I had at that point).

I gotta cut to the chase, and then get some paying work done.


We got by the first few years I was DPM, strictly by using the
paired-programmer methodology.  It was to transfer my knowledge of the
systems, code, and business to the people that worked for me.  Are there any
shops out there that have more experienced and less experienced
personnel...?  Are there any (other than 1-man shops) that DON'T...?!?


Now, I don't make any broad claims to have invented a methodolgy.  That just
clutters up the discussion.  How I found pair programming works is that when
I started this job, they had NO work for me to do.  About drove me crazy.
So I read the manuals, and just hung out with the Asst. DPM.  Watched him
work on the problems that came up, in his daily work.  I was more technical
than he was, so the pairing worked real well.  I acknowledged his superior
knowledge of the business and the systems, and he benefitted by my 38
expertise.  As long as you can find a mutual benefit, paired programming
will work well...

As things went along, I gained the trust of the DPM and he gave me more and
more work.  But still I spent all the time I could working with the Asst.
DPM.. just because I enjoyed it.

After being there about 2 years, the Asst. DPM went down with a heart
attack.  So my "wasted" time turned into an asset.  Then about a month later
(10/2/86, my birthday) I got a call that we'd dropped a 3370, and found out
we didn't have complete backups (except for the systems I was responsible
for).  So that "wasted" time learning whatever I could turned into a
lifesaver.  To make a looooooooong story just looooong, I don't see anyway
possible I could have pieced that thing back together, if I hadn't spent the
time learning from the Asst. DPM.


There are two basic approaches to paired-programming.  The first one I
described is nothing more than an extension of the master/apprentice
relationship.  Which has been used, successfully, for centuries...

The second is a case where two people are masters, and whose knowledge
compliments one another.  I could give more examples of how the
master/master approach is difficult, but well worth the effort.  Don't have
that kind of time, now...


But Brad, Reeve...  It shouldn't even be necessary to write that up, IMV.
Unless you're blind, you can see that happening on this list each and every
day.  I posted recently that I'm willing to learn from anyone who knows
something I don't.  And that includes everyone on the planet, in some
respect or another.

Anyone who takes that POV can work in a paired-programmer team.

My current understanding is that the optimal number of people on a
development team is 3...  But I, personally, haven't tested this theory to
see how it holds up.


Later, Gator, and you too Brad...  (On this, or perhaps another,
thread...;-)

jt

| -----Original Message-----
| From: midrange-l-admin@midrange.com
| [mailto:midrange-l-admin@midrange.com]On Behalf Of Reeve Fritchman
| Sent: Friday, December 07, 2001 8:30 AM
| To: midrange-l@midrange.com
| Subject: "One person per product"
|
|
| This is a great concept (I live it myself) but it requires complete
| understanding of the project and serious coding discipline.  There is a
| school of thought promoting two people working on a project (one
| coding, one
| handling in-line review, etc.); that's interesting as well but
| probably not
| necessary for general business iSeries stuff (but when you're in
| the middle
| of a bunch of API's with pointers flying around like spam from
| DotBizCentral, having somebody looking over your shoulder is
| probably a good
| idea).
|
| If you have a big project, it appears the best thing to do is to break it
| into little projects and limit the people working on each project.
|
| I found an interesting article by an IBM researcher on programmer
| productivity; his message is that a two-minute telephone call really takes
| 17 minutes: two minutes for the call and 15 minutes to get all the mental
| plates spinning again.  This makes you wonder about the efficacy of
| programmers in cubicles and the concept of the open office; I guess the
| solution is to provide a couple of private phone-less mini-offices with
| doors and PC's with development tools only, a coder would take
| residence to
| get privacy and productivity.
|
|
| Read it? I live it!
|
| Our customers ask us how we can develop better software with less
| programmers than our competitors, and I say - because we only let
| one guy work on one product, at least until it is pretty mature,
| when bug fixes are allowed by newer people (scary thought, isn't
| it?) But we follow some strict, commonsense standards that are
| published and explained to everyone, and new people have to work
| under the oversight of an experienced programmer until the quality
| of the code and comments is known, along with their embrasure of
| the standards.
|
| Of course, you have to have pretty good programmers to do this. I
| 've  written a number of VB programs that go over ten thousand
| lines (that seems like a lot to me).Our AS/400 side is all written
| by one person (the best in town, at least), who is happy to tell
| me 'no you can't do it THAT way.'
|
| God bless him.
|
| Brad Jensen
| Elstore.com home of the Niagra - I mean Niagara CD Recorder for
| the AS/400