In this chapter, you learned about process loss and that groups never perform at their maximum potential. As such, teamwork and organizations are investments we pay for, and they should be considered as such.
You also learned that groups are sensitive to social biases. You saw that there are biases in all kinds of groups—software development included—and you need to be aware of the risks.
That leads us to the challenges of scaling software development. As we go from a small group of programmers to interdependent teams, we increase the coordination and communication overhead, which in turn increases the risk for biased decisions. As such, the relative success of any large-scale programming effort depends more on the people on the project than it does on any single technology.
Over the next chapters, you’ll learn about fascinating research findings that support this view. As you’ll see, if you want to know about the quality of a piece of software, look at the organization that built it. You’ll also learn how to mine and analyze organizational data from your version-control system.
So please keep the social biases in the back of your head as you read along; by using the techniques you’re about to learn, you’ll get information to help you make informed decisions and challenge groupthink. Let’s start with how the number of programmers affects code quality.