Here's Why You Shouldn't Program Alone

[KenR]

"Is software development an activity preferred by anti-social, misanthropic individuals who'd rather deal with computers than other people? If so, does it then follow that all software projects are best performed by a single person, working alone?"

The answer to the first question may be a reluctant yes, but the answer to the second question is a resounding and definitive no. I was struck by this beautifully written piece which explains the dangers of programming alone:
    Some folks have claimed that [working alone] presents a great opportunity to establish your own process. In my experience, there is no process in a team of one. There's nothing in place to hold off the torrents of work that come your way. There's no one to correct you when the urge to gold-plate the code comes along. There's no one to review your code. There's no one to ensure that your code is checked in on time, labeled properly, unit tested regularly. There's no one to ensure that you're following a coding standard...

http://www.codinghor...archives/000890.html

[Gothi[c]]

This is true in many cases (though there are exceptions I can imagine,..) but I feel there is a vital part missing to this article:

So you've deceided to not do your beloved project alone,... you have everything lined out of what the result should be, you have some general idea of the classes that should exist in your program, now how do you start composing a team when you don't have money to pay your developers (eg: how do you start an open source team)?

I'd love for other developers to help out with my projects, but I sure as hell don't see anyone jumping to join in. Even a team of one or two would help, but it is probably very very hard to find people that like your project enough to contribute to it.

Another problem is,- at what maturity level does your project have to be, in order to start composing a team? Can your team start from scratch, or should you code the general outlines of the project first, before you gather up a team? .... etc....

Making a statement saying that one shouldn't develop alone is one thing, but one should provide more information as to how to NOT program alone, to provide readers with an alternative. (A solution that does not involve joining an existing project, people want to realise their own ideas and projects and that's how most of us end up coding alone, many times because there's simply noone else interested enough to join in, or because the questions above are unanswered.)

[mouser]

gothic i couldn't agree more with your points, very well said.

[app103]

Getting people to work together isn't easy.

I host a channel for a group with about 60 members, most of which are teaching themselves programming, with a few that hang around to be helpful to the less experienced. (and a few that stick around because they love us crazy geeks)

It happens so often in my channel that someone will get a great idea for something that is just too big for them to handle alone.

A few others will get excited about it and offer to help...even with something specific sometimes. Then we have 2-3 coding... contributing(as soon as they finish fighting about what language to write it in) and then the real fights begin.

Each one thinking that they can do a better job at something that one of the others have done...and they stop working together and begin to compete, rewriting each other's code and going in circles and not going forward to get the project done.

Then the insults start because they are stepping on each others toes.

By the end, they all decide to do it on their own, and we have 3 similar projects in the works...and it's a competition instead of teamwork.

Then they get fed up and quit because the project is too big for one person...and we have a bunch of abandoned projects.

I have had to play peace keeper and referee many times over the last few years. I love them all like family and I hate to see them fight like that. But I haven't found a way to cut their fuses.

When the idea for a small project comes up and it's one single member doing it, I love it...and things go fairly well, and there is usually a finished application for that coder to be proud of.

When it's a big project...it makes me want to run for the hills because I know how it's going to turn out. 

[justice]

Even if you're working on a project together with others it doesn't mean they will improve your process. If you're working with a colleague with a bad attitude and no interest of improving their quality of work than it's actually hindering implementing any quality improvement practices 

Putting two 'good' people together might result in a better product than one 'good' person.

[urlwolf]

Isn't this what extreme programming is about (partly)? In this case, they advocate two programmers sitting in front of the same computer.

I did it once and it was a great experience, even though you think that it's overkill and you are wasting the time of one of the coders. Actually, we spend quite a lot of brain CPU power doing petty things like trying to match a bracet (even though I use vim almighty and it's tuned so it looks like, to the uninitiated, I conjure code with my mind). Meanwhile, the non-driving seat programmer is using his brain CPU to do actual work.

[SkyIDE]

Well, considering this applies to me and many others out there, I can firmly say that having a second coder is not a bad idea. Two brains are better than one and having more than two people is better again. You would have to have some type of protocol that all members must follow and potential conflicts should be resolved that way.