I'm doing both now: my personal project and the project I do in the work (approx. 5 people involved). The personal project is a lot smaller than the work project, it uses a slightly different technology (though not _so_ different).
- General knowledge of project.
Working alone is a real benefit when it comes to knowing what is where. You develop it, you don't waste time on searching for some piece of functionality. It's a huge amount of time you're saving. This is connected to... - Reusing code.
If you don't know of some code, you can't reuse it obviously :) This affects the quality and consistency of your application. Alone, you are almost 100% sure that you didn't create any useless code; in group, there is a good chance that you miss something, especially if your code isn't documented well. - Specifying requirements.
I found out, that if I specify requirements for myself I tend to change them a bit. This is because I am a programmer and I have some general overview on implementation of something. This eases my work but can be tricky, because it can affect the user experience which is the most important thing. - Issue tracking.
This is very important when working in group. You have to be sure that you won't be doing something that someone is doing at the moment. This isn't an issue when you work alone. I found out that a simple TODO file is enough, I just take care of one task at the moment, prioritize the tasks simply by moving lines up/down. This is easy and effortless. - Quality of code.
Alone, you are more error-prone. This is normal, and you don't have to be afraid of it :) When pair-programming you have two people looking at code, checking each other. You don't get this benefit when being alone. This is connected to code reviews/audits. They are also a way of keeping your code clean and of good quality, especially when it comes to some crucial parts of system -- this can be a way to decrease the impact of working in group on general knowledge of project and code reuse.
Having someone who doesn't know programming specifying requirements is in this way better, you can be sure that he/she didn't change some functionality just because it is easier to code. On the other hand such people can be unfamiliar with user-friendliness topic for example, which affects the user-experience obviously. Then you have to talk over the specifications.
My general opinion is: don't expect to get 5-times-speedup on project with hiring 5-times more people -- it's just impossible, due to the communication issues. Instead, you should concentrate on improving the process to gain more.
