More people means that each one of them would need to be brought up to speed on the problem, and then each time we try something out, we'd need to communicate amongst us to make sure this new approach wouldn't adversely affect (too much) what the other folks are trying out. Communication overhead is O(n^2).
There are two stages a software project goes through. In the first, you're exploring the design space and trying to figure out what the constraints are. There's no architecture yet, because an architecture is a reaction to a set of constraints, and you don't know what those are yet. So a change anywhere could result in radical changes to the rest of the codebase. You might find out that the approach you were trying just doesn't work at all and you need to scrap everything and start again.
In the second, you have a basic architecture and a set of users that are happy with the product, and you're trying to incrementally refine it so it has broader appeal and users like it more. Here, developers only need to be familiar with one section of the code, because the basic architecture is set and changes should be fairly well localized. Things like tweaking a UI widget, or adding a new feature, or changing look & feel.
The first situation requires that all developers be familiar with all parts of the code, and so (given the O(n^2) communication overhead) is best done by a single person. The second allows developers to work in parallel on different features, and so is best done by a large team.
This also explains how to reconcile The Mythical Man Month (which recommends a team size of one, plus supporting cast) and open-source software like Linux (created by thousands of volunteers across the globe). Brooks was writing about software systems before they're delivered, when the architecture is first emerging. When Linux was new, it was created by a single developer too. It's only after it became moderately useful that it was opened up and people started contributing patches.
I suspect it's also behind much of the acrimony between the static-typing (Java/C++/C#) and dynamic-typing (Python/Perl/Ruby/PHP) camps. Dynamic languages are much better in phase 1, because they don't enforce interface boundaries when you don't yet know the interfaces. Static languages are better in phase 2, when you have clear interfaces and the hordes of programmers need to know what will or will not break things outside the area they're working on. You can use dynamic languages for this too, but you need to essentially reinvent most of the features of static languages through documentation, testing, and assertions.
I was just commenting on the fact that apparently you have a problem, but not the resources to solve it, it seems that the communication overhead for even one other person would help you see the issues and details needed to solve whatever problem it is that is being dealt with.
