RE: "One person per product"

["jt" <jt@xxxxxx>]

| -----Original Message-----
| From: midrange-l-admin@midrange.com
| [mailto:midrange-l-admin@midrange.com]On Behalf Of Brad Jensen
| Sent: Sunday, December 09, 2001 10:59 PM
| To: midrange-l@midrange.com
| Subject: Re: "One person per product"
|
|
|
| ----- Original Message -----
| From: "jt" <jt@ee.net>
| To: <midrange-l@midrange.com>
| Sent: Sunday, December 09, 2001 9:07 PM
| Subject: RE: "One person per product"
|
|

<snip>

| >
| > Okay, maybe not that exact scenario, but something similar is
| played out
| > thousands of times a day.  The paired-programmer approach is
| nothing more
| > than the extension of this from the area of debugging to the
| area of
| > development.
|
| That's like extending ballroom dancing to bungee jumping.

Those are equally disastrous, in my case...  ROFLMAO...!

However, are you saying you haven't had one coder find another's bug in a
fraction of the time...?  You've tried pair-programming, and not gotten
results?

|
|
| > OTOH, the paired-programmer approach WILL APPEAR controversial,
| because a
| > lot of folks are still looking for panaceas.  There are none.
|
| Sure there are- 'structured programing' 'three tiered development'
| 'object oriented programming'

There are better methodologies and worse...  No panaceas, AFAIK...
Developing quality software is still a bottleneck.  Methods have improved,
but so have demands...

|
| I do use bull pen methodology in design, but not execution. And
| with design touch ups, when hitches develop.

I don't see the great distinction between fixing hitches, and preventing
them in the first place.

I s'pose the concept of the effectiveness of P/A is controversial too,
because I've always found better results with good P/A's vs. when a good
analyst is paired with a good programmer.  I'm aware of the theory that a
good P/A **can't** be as good as either a good analyst or a good programmer,
but have not found that to necessarily be the case, judging by the results
I've seen.