When does diversity work well in a software team? I’m not talking about what you normally think of when you talk about diversity – race, gender, national origin, etc. — but the diversity of experience that you can get by bringing together people who have worked on different types of projects, in different domains, with different languages, etc.
Here’s where having a lot of diversity is suboptimal: when you have a known problem, and one or two super-experienced people who have solved that problem successfully many times. When you’re buidling Yet Another Fucking Decision-Support Dashboard (YAFDSD), you don’t need a bunch of intelligent discourse about threading, distributed processing, data integration, scaling, etc. You just get Drupal or Ruby on Rails or an ASP.NET starter kit, send the team out of the gate with a full head of steam, and get it done. The more experienced and cohesive the team is, the better the result.
However, let’s suppose you have a greenfield project, in a new, unknown problem domain. No one on the team has direct experience with this type of problem. You need new algorithms, storage mechanisms, architectures, etc. In this situation diversity is great — so important, in fact, that if you have a bunch of people that come from the same background, same amount of experience, and same technology preferences, you might fail completely.
You can liken this to a concept in evolutionary programming that says that you need enough initial diversity in your candidate solutions or else you may be unable to find the global optimum.
To use a real world example, if all you have are a bunch of Rails developers from Austin, and you need to do some sort of real-time embedded programming task dealing with sonars attached to dolphins, you will probably be performing suboptimally.
To recap: the more original, uncertain, or unpredictable the challenge, the greater the need for diversity in your project team.