Do you encourage pair programming?
It is not a single question but I have following multiple questions.
- How many appreciate pair programming?
- How did you get management buy-in?
- What are the results? Is it worth an invesment?
- Please share experiences of developers who do pair-programming
Answers (9)
Chris C
1600+ connections, chrisclark@chrisclark.com
Best Answers in: Web Development (5), Internet Marketing (1), Viral Marketing (1), Professional Networking (1), E-Commerce (1), Databases (1), Software Development (1)
Pair programming is great. Getting management buy-in is hard, but the returns are great. It's important to educate management on the technique and the benefits. The results are better code. I think it's worth the investment when justified against the benefits.
Benefits:
1) Code quality. Two heads are better than one. Quality should go up.
2) Slack time should go down. No time to surf the internet when your partner is waiting on you.
3) Redundancy in the process. So there are no silos of information. You don't have to worry about Johnny getting hit by a bus and the whole company going under because of it.
4) Getting the team to communicate. I also think it's important that developers work in an open area, not in cubes. It's good to hear things where you can contribute to others.
5) Ownership. The code should be considered the company's code, not the individuals. So changes and comments are not personal.
Pierre K
Pre-Sales Engineering Consultant for IP Performance Ltd
Best Answers in: Computer Networking (2), Facilities Management (1), Purchasing (1), Government Policy (1), Exporting/Importing (1), Organizational Development (1), Information Storage (1), Telecommunications (1), Software Development (1)
I thought you meant au pair programming - shame, now *that* would be a cool thing, code out inappropriate imperatives at source, so she won't disappear with the family car all weekend, or shag her Polish boyfriend in the kids' bedrooms...
--
Pierre
I certainly do.
Past experiene shows that the average programmer works better and is more productive when given the chance to share his creativity with a colleague who is sharing part of the work. Work tends to be carried out faster and more mistakes are caught early. Individuals are more focused, since the presence of a peer helps in those moments when the mind tends to wander either due to fatigue, too much creative thinking, or when a programmer is overwhelmed by the tendency to add 'one more frill' which many times is unnecessary and may introduce off-spec side-effects.
Development is done within a continuous feedback loop where programmers communicate with each other, can spot-check each other's work and help each other get 'unstuck' especially in cases of very simple mistakes that the author of the code cannot see because his mind is already ahead in what he wants to do next.
There are exceptions of course since some top notch programmers prefer to work solo at their own, usually much higher than average, production rate. Even in such cases, pairing this individual with an average programmer who acknowledges his partner's higher expertise and assumes the role of an assistant, can help enormously both in production and in elevating the skill set of the assistant programmer while taking some of the workload off the expert.
The other side of the coin is that two people instead of one are being used for work on the same unit and this invariably brings on management objections. In most cases, a working argument is that there is always a second person who is thoroughly familiar with the specific work and can take it over in an emergency without delay, know-how is shared and not confined to a single individual which means the project has less single points-of-failure in case a key programmer is removed from the project for any reason.
The results are usually better code quality, increased production, higher team motivation and better communication. The fact that individuals skills also advance faster adds value to the original investment on the team and the bottom line which is adherence to schedule and meeting landmark and completion dates is more easily achieved.
Having done it before, I can't help but feel my and my client's time is being wasted while I watch another senior developer type in scaffolding code and implement getters and setters.
Personally, I think code reviews are a more effective means of controlling code quality (and there is also actual evidence, not anecdotal, that they are).
Sometimes when you are coding, you need several of hours of intense concentration to get something done and having to discuss and explain what you are doing to someone else derails the process, making it take much longer. So, to my mind, productivity is exponentially decreased, because you are spending two people to perform a task that takes much longer.
Basically, if you want to show that pair programming is worth the investment, you have to prove (or make yourself believe) that the reduction in quality of two programmers working alone will result in twice the amount of work than producing the same result with two programmers at the same time. Honestly, I don't buy it.
I have participated in pair programming before. Its utility greatly varies depending on the project and type of code being written. As Dave Copeland noted in his answer, their is not much value in using two people to write simple getters/setters. Any errors there should be caught quickly by the the unit tests.
For moderately complex business logic, having a second person sitting there can be useful to spot errors in assumptions about inputs and system state and to be familiar with the code and logic.
Some of the code I write would not be possible for me to work on with someone next to me interrupting on a frequent basis. There is no way I could concentrate deeply enough to write numerical analysis routines in that environment.
For me, the ultimate answer is that it depends on the type of project and the type of code being written as to whether there is enough value in pair programming to offset the costs.
This is the most efficient way to remove most of the bugs at initial stage.
Eileen B
IT Professional, Information Security Quality Assurance Operations & Administration / President, CMU SEI LI SPIN
Best Answers in: Using LinkedIn (53), Staffing and Recruiting (12), Career Management (12), Computers and Software (8), Quality Management and Standards (7), Software Development (7), Web Development (7), Ethics (6), Change Management (5), Professional Networking (5), Enterprise Software (5), Freelancing and Contracting (4), Job Search (4), Accounting (4), Government Policy (4), Internet Marketing (4), Organizational Development (4), Project Management (4), Education and Schools (3), Business Development (3), Supply Chain Management (3), Blogging (3), E-Commerce (3), Databases (3), Travel Tools (2), Certification and Licenses (2), Personnel Policies (2), Internationalization and Localization (2), Contracts (2), Employment and Labor Law (2), Advertising (2), Public Relations (2), Business Analytics (2), Corporate Governance (2), Inventory Management (2), Manufacturing (2), Personal Taxes (2), Professional Organizations (2), Biotech (2), Computer Networking (2), Commercial Real Estate (1), Customer Service (1), Facilities Management (1), Regulation and Compliance (1), Conference Venues (1), Corporate Taxes (1), Economics (1), Government Contracts (1), Government Services (1), International Law (1), Treaties, Agreements and Organizations (1), Criminal Law (1), Antitrust Law (1), Intellectual Property (1), Direct Marketing (1), Guerrilla Marketing (1), Labor Relations (1), Planning (1), Bond Markets (1), Hedge Funds (1), Market Research and Definition (1), Starting Up (1), Information Security (1), Information Storage (1), Telecommunications (1)
I do! I do! I spent quite a few years of my life on my own programming and was thrilled to have the opportunity to collaborate with another programmer. The best experiences I have had have been with those with opposing skills, this was a learning and bonding experience.
Eileen
I believe pair programming as it is formally defined is difficult to use all the time. As others have said it depends on what is being developed and how complex. I believe that collaboration during architecture design, with constant intermittent updates among developers, especially when adjusting interfaces and exposed properties, will help to accomplish the goals that "pure" pair programming tries to accomplish.
At my company, pair programming is part of our standard development process. I do like pair programming as it is a way to collaborate and write good code as well as a kind of just-in-time code review, if you will. One of the drawbacks I see to pair programming is that it is slower. It is more efficient to have two developers working on different pieces than to have them working on just one. However, you'll lose the benefit of cross-training and the possible benefit of developing better code (two heads are better than one). Overall, I like pair programming. It is slower, but we have found a lot of benefits in it. We tend to get better code, our code reviews are shorter, and we adhere more to "best practices".
