• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Pair Programming Dilema Resolution

 
Ranch Hand
Posts: 68
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Two people are pair programming and they disagree about something significant. Does the methodology have a defined mechanism to resolve the issue. This issue was a question on a job interview.
I thought if I was working with the chief architect of the project, we'd do it his way.
If I was working with a green been, we would discuss it longer.
If no resolution was achieved, we would let management decide the issue.
In hind sight maybe this solution could dump a lot of issues on management they do not want to deal with.

Any thoughts? TIA
 
Sheriff
Posts: 7001
6
Eclipse IDE Python C++ Debian Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The examples in the books seem to recommend an approach involving finding out more about the problem or the proposed solutions before deciding, if the solution is not obvious:
If the disagreement is about which design choice is more "future proof", more "flexible", more "elegant" etc. just choose the simplest solution, and "improve" it only if it really becomes necessary.
If the disagreement is about whether one or both of the design choices will meet the requirements (you may be working on a task to address a performance issue, for example), do a "spike solution" and measure the results.
The only really tricky discussions might be about which solution is "simplest". This is a hard one, but you would probably be best describing both solutions to a third party, and either discovering an answer during the description process (see http://c2.com/cgi/wiki?CardboardAnalyst ), or accepting the decision of the arbitrator.
In any of these cases it's far more valuable to get a solution in place as soon as possible (so that the reefactoring can begin) than it is to spend a lot of effort choosing a "perfect" solution "up-front".
[ March 26, 2003: Message edited by: Frank Carver ]
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Bob Fred:
Two people are pair programming and they disagree about something significant. Does the methodology have a defined mechanism to resolve the issue.


Is this a trick question?
Pair Programming is not about mechanisms, it's about collaboration.


I thought if I was working with the chief architect of the project, we'd do it his way.


If you do this because he has more experience and you wonder wether he might be right, so you want to learn from him by trying his solutin - it might be a good choice.
If you do this because he is the chief architect, it is one of the worst...


If I was working with a green been, we would discuss it longer.


OK.


If no resolution was achieved, we would let management decide the issue.
In hind sight maybe this solution could dump a lot of issues on management they do not want to deal with.


And probably also can't - they don't know the code as well as you do, do they?
Some additional suggestions:
- ask some other team members
- try it both ways, then decide which you like better
- flip a coin (seriously - we once did this, and it worked very well)
All these are suggestions - some might work for you and you have to find out for yourself which ones do. There are no predefined "mechanics".
 
reply
    Bookmark Topic Watch Topic
  • New Topic