The reality is that the amount of code to be written depends on who is writing it. No two programmers will create the same code to do the same thing. Code is an expression of the author's thought process based on his experience, understanding, and style; therefore it is unique to each individual. For example, one person might implement the same functionality in a fraction of the code that another writes, but he may write it in a form so abstract it would be difficult for others to maintain. Coding is a constant process of making trade-offs.
Furthermore, the greater the number of code components you have, the more integration you have to do, which increases the opportunity for rough edges. Also, the smaller the piece of the puzzle each person is looking at, the greater the chance for misunderstanding or crossed wires. Of course this tried-and-true axiom relates to this situation all too well: "Too many chefs spoil the stew."
From this standpoint, the fewer developers the better. In my opinion, two is the ideal. You get a check and balance and don't have a single point of failure. Of course there are some projects that lend themselves naturally to three developers, or even as many as five, based on how loosely coupled the components are. With clearly defined boundaries, integration is easier.
But the real point—which is hard to maintain focus on in a time when everyone is in a hurry for everything—is that less really is more. What does this mean?
- Don't substitute quantity for quality. Learn to question offers for more people, as tempting as it sounds. Push for better people instead.
- Look past the deadline. Think about how the decisions you make today will affect the future.
- Do the math. Is it really worth $1.8 million (an extra 151 man-months at $12K per month) to save twelve calendar days for the first release—then pay premium maintenance costs for the rest of the software life?
Maybe the hardest change of all is to resist the all-too-human urge to build an empire, believing that the more people you have, the more power you wield. Instead, look at each resource as a layer of complexity: The more you have, the more it costs—and, in the case of software, the less you get—and the worse it is.