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.
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 ]
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.
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".
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Onion rings are vegetable donuts. Taste this tiny ad:
create, convert, edit or print DOC and DOCX in Java