问题
Pair programming in Agile requires us to double the salary paid to single programmer. Of course with such approach the quality of the code is far cry better, bugs are found much earlier and so forth, but is that still worth that money? Maybe we should pay the 2nd developer's salary to the few testers (the latter are usually much cheaper than the qualified programmer)? Does anybody have any experience with such comparison?
回答1:
How do you know your unpaired programmers are any more efficient ? I sometimes think the single/pair is comparable to the old fairytale of the rabbit and the tortoise.
Pairing doesn't drift off into days of counter-productive work. I have no idea of how often I've seen developers spending weeks working on stuff that later turns out to be replaced by something far simpler. The single programmer "in the zone" often does stupid things. It's just too easy to produce too much code, when what you want is more punch with less code.
And in posterity, when the dust settles, you find hundreds, if not thousands of lines of code that could have been not written because someone didn't know about library X or technique Y. Pairing improves this problem, but does not remove it. It encourages both individuals and the pair to do more research before diving into mindless code euphoria.
I wish I was able to pair more....
回答2:
We use this approach in our company, but only for the difficult tasks or when you're unsure about something someone else has worked on already which I believe works very well. It saves you getting stuck in a rut and being able to bounce ideas off people where necessary while still being able to work independently for most simple tasks.
I also believe it is more beneficial than a code review, which is something else we do where I work. It is often difficult to know fully what's going on when doing a code review without providing significant context, at which point you don't always have the time to think about all the in's and out's. Pair programming gives you that context from the start and allows you to spend more time thinking about edge cases that may or may not cause problems.
回答3:
Although I agree with most of the response so far about pair programming being a good thing, I will play devil's advocate and argue that it doesn't always make sense.
When you pair you don't get a programmer that's got twice the brains. You get a programmer that's the union of both of your brains. So basically any time that I screw up and my partner catches or finds some way better, it's a plus. However, any time that I write the correct code on my own is a waste of money since my partner wasn't needed.
Basically, you need to evaluate the code you're working on. Simple tasks are usually not worth the money to pay someone to sit over shoulder and make sure you wrote your for loop correctly. However, at some threshold, the tasks are complicated enough to make the roi for pair programming justifiable.
回答4:
With pair programming, you combine:
- Higher quality code
- Better distribution of inner knowledge
- More team spirit
You won't get that much return on investment easier than that.
Then again, you shouldn't use it for all tasks.
回答5:
It does not mean double the cost if it takes less than 1/2 the time it would have taken with one dev. I think on difficult or low-level tasks this would be helpful. I find that it's worth it because you've got someone to say "no, don't do THAT!" long before it ends up in production code where it will REALLY cost you time and money.
I've written operating systems and things of that nature where it was invaluable that someone was sitting next to me to double check my logic.
回答6:
At work we use pair programming all the time. The trick is to know which tasks should be done in pair and which would be a "waste of time" if done by two developers. The rule of the thumb is that tasks that are more research oriented (i.e. POCs & spikes) should be done in pairs as well as development of new features (so that the knowledge will exist in more than one mind). Tasks that are more mundain such as CI server installation or replacement of the addon icons is done by a single developer. Another factor is the current availability of team members and the current tasks to be done at that iteration.
回答7:
No, you don't. Each programmer still gets exactly one salary.
Do you think your programmers won't talk to each other if you don't call it "pair programming"? Do you think programming is perfectly parallelizable?
回答8:
It's hard to say - I've spent a lot of time working in a force-paired environment and also in a pairing-optional environment. The highest quality code I've seen is not in the paired environment. That probably has more to do with the caliber and discipline of the individual developers. Sometimes you'll get your money's worth from pairing, especially where some of the coders are not top-tier. But if all the coders are experienced, well-disciplined coders, you're just wasting your money if they're pairing all the time.
One type of experience that I've had multiple times that has a huge impact on my coding discipline and the quality of product I produce is this: carrying a pager. When I have to support a system for which I code, it changes how I code. That is, I code in such a way as to keep that pager from going off. The result is a better quality product, and typically better code quality, too. The coders I've seen that have never carried a pager produce code that's more fragile. It's not something that they can even understand and improve upon until they've been on support.
回答9:
Pair programming can be amazingly effective, however you shouldn't be hiring programmers in pairs. You can't force developers to pair program. It only works when two developers click and decide they can learn from each other and build something awesome together. My advice is to hire as many of the smartest developers you can find and put them in a setting that naturally lends itself to encouraging part-time pair programming. Developers need to be able to code alone, but also talk to others on the team about it.
Finding the right mix that works for you and your company will be more art than science, and certainly not something you can do by blindly following the demands of some published methodology.
That said, the more bugs you squash before they ever get checked in, the more you save in the long run. Having another developer looking on as you architect something will always be more effective than having a tester black-box it afterward. I'd call it money well spent.
回答10:
The sooner a bug/defect is found the cheaper it is to fix, so using the money to hire more qa people vs another developers, is going to cost you more time/money because of how many trips from DEV to QA.
Having said this, pair programing don't work with everyone, some developers don't pair well, they distract each other, spend all their time fighting, etc.
If you have developers that can pair program, it can be more then beneficial in the long run when you add in more maintainable code, lower defects so less time in QA, and most importantly if one of the developers get hit by a bus, you don't have to wait for someone to come up to speed on a project before any more work can be done on it.
If your developers can't pair program don't force them into it, all you're going to do is waste time and money.
回答11:
The first assumption one makes with pair programming is that a story card will cost twice a much to develop. The assumption is faulty. Here is why?
- Improved quality: A pair of active programmers working on the same story card will complete the card with less defects
- Improved productivity: a pair is less likely to be slowed down if not outright blocked when solving a problem. Furthermore, it is harder to take an email or web vacation when you are working with a partner ... you don't want to let the partner down. You will solve the problem with a cleaner design and less lines of code when working as a pair
- Eliminate silos of knowledge: With rotating pairs, you will learn application and domain business knowledge across the team. The team is less likely to be blocked because Sue when on vacation and no one else knows her code.
- Knowledge Transfer: Rotating pairs teach new skills (engineering and domain) to each other as they work together. The level of the team will rise for everyone and the knowledge propagates through the team.
- Team self selects: The team learns one anther's skills and will quickly weed out someone that is not performing.
From actual experience we have seen defect drop significantly. New team members can be added without slowing down the team (try that with a non-paired team). For a trial, one team estimated the work for a set of story cards as if six single developers would complete the code individually. The six developer were then told to pair. They completed the work on time with high quality. If you don't pair, you are spending to much time to deliver to little quality, you have no way to scale and you have too many silos of expertise.
In a second example, we estimated to complete the work in the time requested we would need to take a team from 4 pairs to 7 pairs. We gave ourselves 1 month to on board the new pairs. We paired a new developer with an experienced developer and rotated the pairs across story cards. The team hit all deliverables with quality in the time planned. Without pairing one could not have added 6 developers to a team of 8 developers and hit the mark!
Bottom line, you will save money with pairing. You will take about the same time, delivery with higher quality, improve the teams performance, skills and knowledge and weed out the dead wood. Your savings will come with sustainable pace and significantly fewer defects in the way to slow the team down.
回答12:
Pair programming doesn't double the cost - it just halves the amount of typing. Typing isn't programming. Completing the functionality in the software is programming. It's problem solving. You can't just measure it in lines of code typed. Some programmers will use a better algorithm so they end up typing less.
How would you define value for money? Possibly total time elapsed between start of coding and completed, working feature in live?
The cost of not pairing isn't often counted correctly: The problem is that most people don't measure the number of defects or the amount of extra time taken to fix work that wasn't completed properly in the first place - they just measure the time taken to "throw the work over the fence" in the first place.
There are a few attempts at measuring productivity when paring, but unfortunately it gets a bit tied up with "number of lines of code delivered" - which is a bogus metric.
You might find this study relevant: http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF
回答13:
The premise is that your productivity more than doubles. Part of the gain is realized right away (e.g., before code is checked in) and part is realized further on, when there are fewer bugs and failures.
When I teach students with two semesters' experience, for most pairs their productivity more than doubles because they ask each other questions and they learn and finish faster. But it's not universally true; a badly matched pair can take longer and do worse than the more skilled half.
回答14:
Quality management experience from other many industries teaches us that defect prevention is cheaper in the long run than defect detection (also known as QA) and subsequent fixing.
They also learned that the long run ranges in most cases from 1 to 2 years, which means that your investment pays off after that. Considering that investments on that scale are usually expected to reach a break even after 4 years, this is pretty good!
The problem is that it took the other industries several decades to accumulate enough data for being able to prove that this is the case for them. You can easily find data to support their conclusion and draw a conclusion for software in analogy to that, but as of today, there is no proof for the software business.
That being said, I believe that the analogous conclusion is valid: A pair of developers and one tester are more productive than one developer and two testers.
If you have problems justifying two expensive developers sitting in front of one computer to the managament, there are many other things that help with defect prevention, but are not as visible (and therefore irritating) to the management.
回答15:
When I am programming on my friend's boat we don't always have time because one of us is sailing it while the other is coding. However, when we are anchored or in calm water we can do pair programming and it works fine.
回答16:
No way man! in the company i'm working we practice a lot of pair-programming! it gets things done really fast and really efficiently! just make a try! you will valuate it later!
回答17:
Professor Laurie Williams from NC State is the primary authority in academia about the effectiveness of pair programming, she did a whole bunch of studies on this.
If you want the "official word", visit her publication list.
Her article: "Strengthening the Case for Pair-Programming" is extremely famous.
回答18:
It depends on the developers. Unfortunately, you can't just stick any two developers together and expect timely, high quality results. Not everybody is cut out for paired programming or even cut out for working in an agile development environment. Two things about paired programming that I think make it worth while are : (1) Cross-training between developers; and (2) Real-time peer reviews. Cross-training will help to strengthen the skills of the team as a whole, and real-time peer reviews can eliminate the need for formal peer reviews. I've learned more from my peers over the years than I ever learned at a technical training.
回答19:
Unless you are a very tiny shop, you are probably already paying the salaries of two programmers. Pair programming is just a way to (theoreticaly) get more debugged and working software out of those two in the same amount of time.
回答20:
It's not a black and white thing or a silver bullet of any kind, the concept of pair programming.
Pair programming is generally extremely efficient for various reasons, but done right it's also very exhausting (in my opinion any way) - meaning a good pair might pair program a few hours a day at most. This should be encouraged, of course, but not mandated and especially not mandated at 100% time because that seems hard to manage (with sustained efficiency and no beer anyway).
So, pair programming is just one way of approaching a problem, and I find it hard to look at it from the question's perspective. It's not like you need to hire twice as many developers for this. It's like wondering if it's worth hiring a message boy/girl to have two employees in the same department talk to each other... when the obvious solution is to have them talk to each other directly without an additional messenger.
回答21:
I haven't done the stats--and I suspect you'd have a hard time doing a statistically valid study--but keep in mind the ostensible objective of producing working, error-free code--not just quantity of code. A good pair should be able to create at least as much correct code as two programmers working separately.
来源：https://stackoverflow.com/questions/668158/pair-programming-means-double-cost-per-developer-is-it-worth-that-money