In the Beginning, There Was the Sandbox
Products come out of projects, and projects tend to begin in haphazard ways. Organizations with well-defined processes have developers building their components in local work areas, sometimes called sandboxes. They provide for mechanisms whereby the subproducts of these sandboxes can be assembled, sometimes in ad hoc ways, so that each development team can test its progress in the context of the whole product. Configuration management systems allow for appropriate partitioning such that each developer (or team of developers) has the autonomy and isolation to work on his piece without stepping on the other guy’s toes, while at the same time providing for a loose integration context.
This works fine in the early, chaotic days when everything is changing very rapidly, and before architectures are well-defined and interfaces are nailed down. However, before too long even modest projects outgrow this framework. At that point, one of two things happens: Either the organization makes the build a priority and adds some structure, or it doesn’t. In general, those that do establish a regular "heartbeat" for the project—a periodic, regular, and dependable build cycle—improve their chances for success. Those that don’t establish this rhythm find that entropy begins to take over, and that building the product becomes more difficult over time.3
Many organizations vastly underestimate the effort it takes to put a good build process in place. Because of this, projects in their latter stages often have a "new" problem to deal with: In addition to having buggy software, incomplete parts, and so on, they also struggle with something that they have taken for granted—the simple assembly of their product. This is a trap for the unwary. In order to not fall into the trap, you need to understand more about the process of assembling a product.