Timeline for How common is pair programming in the workplace?
Current License: CC BY-SA 2.5
24 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 9, 2013 at 17:47 | comment | added | JeffO | If you've ever had to clean-up someone else's code, you've been implementing paired-programming in the worse way and just didn't know it. | |
| Mar 5, 2011 at 21:08 | comment | added | TZHX | There's a difference between utilizing paired programming development when it makes sense, and doing it full time. I really don't think doing it full time would be a good thing. @Michael - reductio ad absurdum isn't really a fitting way to engage in discussion in the real world. | |
| Mar 5, 2011 at 20:46 | comment | added | Michael K | @TZHX Not to be argumentative, but extrapolating your "poor business decision" would indicate that it's a waste of money to have more than one person on a project. After all it's more than one salary for one output. | |
| Mar 5, 2011 at 12:38 | comment | added | TZHX | @Chad - I agree on typing. I don't see how your comment is in any way a response what I've said. | |
| Mar 4, 2011 at 20:51 | comment | added | CaffGeek | @TZHX, programming is about as much to typing, as writing a book is. Programmers solve problems. Typing is merely the means of documenting a solution. And two people, working together to solve problems will almost always work faster and get more done, than two programmers working individually. | |
| Mar 4, 2011 at 20:36 | answer | added | Servius | timeline score: 3 | |
| Jan 26, 2011 at 21:25 | comment | added | Martin Wickman | @TZHX: Fair enough. My experience is that pairing makes you at least as effective as two separate developers. Here is a paper on the subject: mitchlacey.com/docs/XR4PromiscuousPairingandBeginnersMind.pdf | |
| Jan 26, 2011 at 19:54 | comment | added | TZHX | @Martin Wickman: I've yet to see or hear of a situation where having two full time developers permanently pair programming is feasible. It has it's use cases, but generally they're limited. But my comment was just a comment, as I'm not really that experienced in such things, was only giving a gut reaction based on what I've seen, read and done. | |
| Jan 26, 2011 at 17:51 | comment | added | Martin Wickman | @TZHX: "Two people for one output is poor business". That is a seriously flawed argument and you know it (like paying programmers per line of code). Pair programming is a complex topic and should not to be dismissed so easily. | |
| Jan 26, 2011 at 14:25 | history | edited | ozz | added pair-programming tag | |
| Jan 25, 2011 at 17:14 | answer | added | Edward Strange | timeline score: 9 | |
| Jan 25, 2011 at 16:41 | answer | added | CaffGeek | timeline score: 9 | |
| Jan 25, 2011 at 16:03 | vote | accept | ozz | ||
| Jan 25, 2011 at 16:01 | vote | accept | ozz | ||
| Jan 25, 2011 at 16:03 | |||||
| Jan 25, 2011 at 15:49 | comment | added | DevSolo | @Michael, not always, but sometimes I thinking pairing on legacy code can be useful. It can break down silo's and/or reduce refactoring costs. That said, I completely agree w/ you. | |
| Jan 25, 2011 at 15:44 | answer | added | Brian Knoblauch | timeline score: 5 | |
| Jan 25, 2011 at 15:39 | answer | added | DevSolo | timeline score: 20 | |
| Jan 25, 2011 at 15:37 | comment | added | Michael K | For new code I think pair programming has great value. The first iteration may take the same amount of time, but IME you spend much less debug time. And when two people know the same code, debugging becomes easier, because they can look independently together. "Given enough eyeballs, every bug is transparent." | |
| Jan 25, 2011 at 15:35 | answer | added | Pemdas | timeline score: 11 | |
| Jan 25, 2011 at 15:33 | comment | added | Walter | Very hard to convince the pointy haired boss that this has value. | |
| Jan 25, 2011 at 15:33 | answer | added | 9000 | timeline score: 5 | |
| Jan 25, 2011 at 15:26 | comment | added | TZHX | I think the PHB may be correct in this situation. Two people (and hence two salaries) for one output is fundamentally a poor business decision. There aren't a lot of cases where paired programming is more productive than individual, at least not "full time" - so it's just not done that much outside of mentoring new staff members or joinly working on a specific problem. | |
| Jan 25, 2011 at 15:26 | comment | added | Michael K | I wish we used it at all. My programming team on my senior project was the only team that used it (we could use whatever methodology we wanted, as long as we had a plan) with great results. | |
| Jan 25, 2011 at 15:20 | history | asked | ozz | CC BY-SA 2.5 |