Moving the Block

[ Team LiB ]

Moving the Block Looking back many centuries before the California Gold Rush, suppose that you were working on one of the ancient pyramids and were given the assignment to move an enormous stone block 10,000 meters from a river to the site of a pyramid under construction, as shown in Figure 2-1. You are given 100 days to move the block and 20 people with which to move it. Figure 2-1. One way to think of a software project is as a heavy block of stone. You must either move the block one day closer to the final destination each day, or you must do something that will enable you to traverse the remaining distance in one less day. You are allowed to use any method you like to get it to its destination. Each day, you have to move the block an average of 100 meters closer to the pyramid, or you have to do something that will reduce the number of days needed to travel the remaining distance. Some block-moving teams might immediately begin pushing the block, trying to move it with brute force. With a very small block, this method might work, but with a heavy block resting directly on desert sand, this approach won't move the block very quickly, if at all. If the block moves ten meters per day, the fact that it is moving at all might be satisfying, but the team is actually falling 90 meters per day behind. "Progress" doesn't necessarily mean sufficient progress. The smart block-moving team wouldn't jump straight into trying to move the block with brute force. They know that for all but the smallest blocks, they will need to spend time planning how to move the block before they put their muscles into it. After analyzing their assignment, they might decide to cut down a few trees and use the tree trunks as rollers, as shown in Figure 2-2. That will take a day or two, but chances are good that it will increase the speed at which they can move the block. Figure 2-2. Whether moving a block of stone or creating computer software, the smart team takes time at the beginning of the project to plan its work so that it can work quickly and efficiently. What if trees aren't readily available, and the team has to spend several days hiking up river to find any trees? The hike is still probably a good investment, especially since the team that begins by trying to use brute force will only move the block a fraction of the distance needed each day. Similarly, the smart block-moving team might want to prepare the surface over which they'll be moving the block. Instead of pushing it across the sand, they might want to create a level roadway first, which will be an especially good idea if they have more than just this one block to move. A really sophisticated block-moving team might start with the roller and road system, and eventually realize that having only the minimum number of rollers available forces them to stop work too often; they have to move the back roller to the front of the block every time they move the block forward one roller-width. By having a few extra rollers on hand and assigning some people to move the rollers from back to front, they're better able to maintain their momentum. They might also realize that their pushing is limited by how many people can fit around the block's base. They might create a harness so that they can pull the block from the front at the same time they're pushing it from behind, as illustrated in Figure 2-3. As more people divide the work, they find that each person's work is easier, and the faster pace is actually more sustainable than the slower one. Figure 2-3. Smart teams continuously look for ways to work more efficiently.

[ Team LiB ]