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 projecta periodic, regular, and dependable build cycleimprove 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]

[3] Entropy is the tendency that all systems have to move from an orderly state to a disordered state when left alone. It is a fundamental physical law. One might say that all attempts at progress, by any civilization, fly in the face of entropy. Another way to say this is that to bring order out of chaos takes work, and that once you stop working, entropy will cause the system to spontaneously move to a more disordered state. I will talk some more about this in Chapter 18, "Bad Analogies."

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 grantedthe 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.

The Software Development Edge(c) Essays on Managing Successful Projects
The Software Development Edge(c) Essays on Managing Successful Projects
Year: 2006
Pages: 269 © 2008-2017.
If you may any questions please contact us: