Jim, This is why I reject the statement that the paired-programmer approach is "controversial". I can't imagine any "sometimers" and even a lot of today's hot-shots haven't run into the following scenario. After hours of furious head-scratching and incantations, one programmer asks others to help debug a program. After a few minutes, one person says "That line right THAR... ICBW, but looks like you don't want that asterix on column 7...!" 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. OTOH, the paired-programmer approach WILL APPEAR controversial, because a lot of folks are still looking for panaceas. There are none. So many, if not a majority of, shops will dive into this head-first (with both feet...;-) without checking the water depth first...! They'll ignore the obvious: "Obviously, this is most effective when two people have worked together over time and have a mutual respect for each other, and know how to get the most advantage out of each other's strengths." They'll figure if a little of this approach is good, then it'll be better still to pair folks 8-hours a day (or 10, 12, 14...) Instead of using the centuries-old methods of apprenticeship, they'll take their 2 TOP PERFORMERS and immediately pair THEM (when this is the most difficult of pairings to pull off), and probably give them the BIGGEST project the dept has EVER attempted, to boot. And they'll probably get disastrous results, as a consequence.. giving the methodology the kiss of death...: "controversial". I've said I've used this method with some success, and I hope the above clearly points out that I've used it with some disastrous results, as well. I could be havin one of those moments, but IIRC, the statistics on large projects is that only 1 out of 4 ever get completed (not to even bring up the question of whether the implementation was successful, or within time/cost budgets). If that's the case, and it wouldn't surprise me, I don't know why anybody'd be looking for panaceas to fix the problem... Nor why they'd pursue revolutionary methodologies, in the hopes of finding that panacea. JMO. jt | -----Original Message----- | From: firstname.lastname@example.org | [mailto:email@example.com]On Behalf Of Jim W | Sent: Friday, December 07, 2001 3:34 PM | To: firstname.lastname@example.org | Subject: RE: "One person per product" | Importance: High | | | JT, | | I can agree more. Now matter how long someone's been around, there are | times you run into something new, something complicated or | something totally | convoluted. Many times it can be much more efficient for two people who | complement each other to look at a problem and "bounce" things off of each | other. They will usually come up with the resulting solution - | much faster, | and in many cases one that is better than either could have come up with | alone. Two individuals usually look at things from a slightly different | angle. This allows one to see things right away that the other | doesn't. I | think this is especially true when a project "goes where no programmer has | gone before." | | Obviously, this is most effective when two people have worked | together over | time and have a mutual respect for each other, and know how to | get the most | advantage out of each other's strengths. (Not unlike your | example.) I have | worked for 15 years with one of my colleagues, and from time to | time we have | worked together on the same project. In most of those cases, it was when | the project covered new territory. A few times one of us started | the work, | but got nowhere fast, until we got together and started bouncing | ideas back | and forth. People sometimes say that certain individuals "feed | off of each | other." I think in some cases this is true. Each one of us seems to be | able to build on the last idea of the other. It's like doing a big puzzle | and being stuck, until someone grabs the piece that fell on the floor and | puts it in, then all of a sudden things really get moving. On | many projects | one of us would have much better ideas about how to present | certian thing to | the user, or how to handle authority issues, or communication issues, etc. | | One person can't always see everything. Can't see all the angles, all the | problems, all the solutions, etc. IMHO (based on 20+ years exp.), two | people who work well together are more efficient than one, and | usually come | up with superior results in less time overall, than either would working | alone. | | It may be all it's worth, but that's my $.02. | | Jim Whalen | | | ----Original Message Follows---- | From: "jt" <email@example.com> | Reply-To: firstname.lastname@example.org | To: <email@example.com> | Subject: RE: "One person per product" | Date: Fri, 7 Dec 2001 09:49:22 -0500 | | I agree with most, but not all... | | <SNIP> | I don't necessarily agree with the one-man approach however. | | <SNIP> | | 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...?!? | | <SNIP> | | 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... | | <SNIP> | | 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... | | <SNIP> | | The second is a case where two people are masters, and whose knowledge | compliments one another. | | <SNIP> | | 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. | | <SNIP> | | Anyone who takes that POV can work in a paired-programmer team. | | <SNIP> | jt | | | | _________________________________________________________________ | Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp | | _______________________________________________ | This is the Midrange Systems Technical Discussion (MIDRANGE-L) | mailing list | To post a message email: MIDRANGE-L@midrange.com | To subscribe, unsubscribe, or change list options, | visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l | or email: MIDRANGE-Lfirstname.lastname@example.org | Before posting, please take a moment to review the archives | at http://archive.midrange.com/midrange-l. |
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.