views:

111

answers:

4

I'm looking for information, articles, sites, or opinions on what are the benefits and the weaknesses of both:

  1. pair programming
  2. solo programming (single developer)

Why we use agile methodologies like extreme programming?

And the most important question for me:

What is the difficulty with using traditional software development?

+1  A: 

This is a very straight topic so you can find thousands of resources just by a google search. But I post the Wikipedia links that contains enough information + a large set of links to other articles.

Extreme Programming

Pair Programming

Chathuranga Chandrasekara
+3  A: 

My opinion: As you know, it all depends. I've done a lot of both and can say that pair programming is by far the most effective when you're on a team that needs to solve something with a complex business logic.

Pair programming

1.1 You are not wasting time sitting on hacker news or anything. It's just not possible.

1.2 You are sharing what you learn as you go along.

1.3 The code gets so much better when two people are writing. More concise and easier to read because you are sitting next to a potential critic.

1.4 Less need for a code review.

1.5 You learn so much from sitting with someone else code wise and team wise.

Solo programming

2.1 You decide how it's going to be.

2.2 There is more of a try/fail approach that might be educational.

2.3 If we're talking about a straightforward task, working alone can be more efficient.

2.4 You get a sense of owning the code, with all the good and bad associated with that.

As for websites: There are a vast amount of it out there. I suggest going on parleys.com or reading Kent Becks blog.

Espen Schulstad
I'd give +10 if I could for 1.1. I did very well last two days with my peer. He's on leave today (plus today is Friday) and here I am wandering about in SO.
Amarghosh
+1  A: 

Pair programming nominally halves your productivity (you have 2 people doing the job of 1), but proponents claim that the benefits (better quality, immediate feedback) outweigh this.

A single developer who is very competent can be very, very productive because there is no communication and coordination overhead or waste, but still, the scope of projects a single developer can realistically tackle is very limited. And if the developer is not extremely competent, the lack of people to ask for help (or just feedback and ideas) can be a problem too.

Why we use agile methodologies like extreme programming?

Because they are much better than sequential processes at dealing with unclear or changing requirements.

What is the difficulty with using traditional software development?

They suffer from too long feedback cycles, especially where requirements are concerned. In the worst case, your software is complete and tested when you first show it to the customer and find out that several basic assumptions were wrong and you misunderstood core requirements, and you can basically start over from scratch, your entire efforts wasted.

Also, some traditional "heavyweight" processes require you to spend a lot of time on nonproductive stuff like soon-to-be-obsolete design documents and process documentations.

Michael Borgwardt
Good points, but I'm not sure pair programming really halves your resources. I tend to believe that there is less slack time when working with another, so it probably looks more like 60-70% productivity.
UpTheCreek
A: 

I'm a bit challenged to make absolute generic statements in favor of any development approach. I've seen a lot of different approaches and their value typically depends on whether they fit the needs and whether you achieve the desired outcome.

For example you can argue that one of the principles of agile approaches is an increased level of communication between all participants. On the other hand you can find teams with very traditional approaches that expose substantial level communication. So is this in favor of agile or of traditional?

I've never met a team that is using a development approach "plain vanilla" straight from the text book. All successful teams (your choice of "success") have adapted their chosen development approach to some degree.

Bottom line: I don't think that one or the other approach is better 'per se'. It depends on what you do within. Or in simple terms: You can have the best hammer in the world, but to get a screw into a piece of wood the screw driver is probably the better tool.

John