I work in an Extreme Programming team, pair programming every day. Recently more and more often I get to do stuff that gives slow feedback, on order of 3 minutes. For example: change some thing, recompile, run and see wheather the performance is improved. I see it coroding the quality of pair programming, and I think it affects pairs more that solo programmers. If I am alone I can do sth else, but what if I am pair programming? How would you deal with it?
+3
A:
your mileage may vary, but i consider pair programming on anything less than a major feature to be a waste of at least one programmer's time
Steven A. Lowe
2009-01-12 22:10:16
I disagree completely. When both are at a comparable skill level, even simple tasks are done with less errors, as the code is instantly reviewed. Quite many errors are introduced when doing "less than major features". (from my experience, especially when doing "easy to add" features late.)
blabla999
2009-01-12 22:45:54
@steven--Picture how much code is in a large type project you've worked on. Now, how long did it take your team to write (in man-years). How long would it take you to retype? Typing is such a SMALL % of what you do in a project, that it almost factors completely out, hence pairing loses nothing.
Bill K
2009-01-12 23:59:39
@[Bill K] @[blabla999]: read the OP question carefully, he says "change some thing, recompile, run and see wheather the performance is improved." This is NOT a significant feature worthy of tying up two programmers. Pair programming is for feature creation, not trial-and-error optimizing.
Steven A. Lowe
2009-01-13 01:16:34
Still, and especially when doing "trial and error optimizing", errs are introduced so easily (Bob says "do we need this X ? No, let us try without..." Fred cries: "stop ! thats the lock for the fooBarProblem. If you remove that, it will crash in this and that situation"). Know what I mean ?
blabla999
2009-01-13 15:42:39
@[blabla999]: personally, I would smack both Bob and Fred on the nose with a rolled-up newspaper for doing things willy-nilly like that. Trial and error optimizing is a BAD IDEA in the first place. NOT a feature. Don't do it, paired or otherwise. Sheesh!
Steven A. Lowe
2009-01-13 18:50:36
mhm - wasn't it you, Steven, who labeled "change, recompile, run and see if improved." as "trial and error optimizing" in the first place ? Then, if you condemm that as being a BAD idea, isn't it better to do something bad in a pair (controlling each other, at least), than doing it alone ?
blabla999
2009-01-15 15:13:08
@[blabla999]: by that logic, it would be better for the entire team to do something "bad". It is still a bad idea, even if you involve the entire team. If you must do this kind of hacking - and profiling/analysis is simply not possible for some reason - then by all means get help to spread the blame
Steven A. Lowe
2009-01-15 15:30:03
Whether or not this answer is valid, it doesn't answer the question and it's totally unhelpful.
TM
2009-03-21 14:18:27
@[TM]: "don't do that" is a perfectly valid and helpful answer. If the OP had asked "Should we jump off this bridge head-first forward or backward" the valid and helpful answer would be "don't do that" ;-)
Steven A. Lowe
2009-03-23 01:07:29
+1
A:
You should probably consider refactoring the process. Three minutes to get feedback is too much both for pairing but also for coding solo. It is killing your productivity to have to switch gears constantly. You probably just feel it more when pairing.
Rasmus Faber
2009-01-12 22:13:16
+4
A:
If you could do something else alone, why not when pairing? Maybe simpler action items could be taken off an issue list while waiting? A 3 minute wait would be too long for me to keep the brain in the "flow-mode". So being disrupted anyway (and your partner as well), can't you just do something else with your partner?
However, in your situation, I'd not work in any environment where I have 3 minutes pauses after a change. So the question is: can't you develop and debug that code in a smaller environment, broil it to perfection and then reintegrate those pieces into the main stream ?
blabla999
2009-01-12 22:40:30
+1
A:
Pair programming should be applied only to the research/POC/innovative parts of the development. Simple tasks should be delegated to the single programmers.
It is not only the problem of the waste of time when you have to wait for your partner to complete the tivial but time-consuming task. There is also a human factor - you get bored while waiting. Remember that productive developer need to be constantly motivated - waiting for your partner to complete lowers your morale.
Henryk Konsek
2009-03-21 14:13:04
A:
Time for a spike Performance has to be built in, not added on. The team should have a set of automated test that can run frequently (daily) in a production like environment. Also, the team should be running a profiler continuously. If you don't have either, time to stop the line and get it done now!!!
If the team finds itself in a situation where performance is an issue, it needs to identify the technical debt and create a set of story cards to address the debt. It would include a set of automate performance test, A set of profiler tests. Daily analysis of the results of the test is a must. An architectural or design spike can then be called should a performance issue present itself.
If an team has not been doing performance testing continually from the start, you could have a significant technical debt to address. Once you have the application performing, you need to keep running your automated testing daily so you can become aware if and when a problem arises. You are then better to identify the offending changes to the applications.
By running automated performance test, you can allow the test to run for some period, generally for a period of hours. The results can later be analyzed and it frees the developers to do work on other story cards without waiting for the result of numerous individual performance tests.
Waiting is a blocker. Eliminate waiting via automated tests.
Cam Wolff
2009-05-17 23:04:23
A:
It doesn't matter if you are pair programming or not. 3 minutes is way too long for getting feedback on code change even if you are coding alone. I would profile and break down the project so that I can focus on a smaller pieces. In that sense, XP is actually helping(forcing) you to improve the design before it's too late.
Kai Wang
2009-05-17 23:22:22
+1
A:
Performance work, where of necessity you must run for a few minutes to gather statistics, is something that isn't a great fit for XP. There's a strong case to be made for starting off as a pair to sketch out some ideas, then going solo to avoid wasting two people's time for every three-minute performance runs, then joining up again to review the work prior to checking in.
Dave W. Smith
2009-05-17 23:24:41
A:
I would split up for those tasks. Both of you work on the code separately, and recombine every so often (30 minutes or so?) when you've made improvements.
ChristianLinnell
2009-05-17 23:29:35