Moving the Block

A recent post by Wesner Moise after a two month haitus got me thinking about a passage from Steve McConnell's After The Gold Rush. Like all Steve's stuff, it's great, but the title is unintentionally ironic: the book was released in 1999, at the very height of the dotcom gold rush. The last thing on most developers' minds was the profession of software engineering-- they were too busy finagling ways to cash in or cash out.

Anyway, in the first chapter, Steve draws an analogy between starting a software development project, and building a pyramid. The task can seem so monumental, so overwhelming, that it's difficult to even know where to start. Well, with the first stone block, of course. Isn't that easy enough?

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 move the block 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 Fool's Gold approach won't move the block very quickly, if at all. If a team moves the block 10 meters per day, the fact that the block 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. That plan will take a day or two, but chances are pretty good that it will increase the speed at which they can move the block. What if trees aren't readily available, and the team has to spend several days hiking up river to find some? The hike is still probably a good investment, especially since the team that begins by trying to use brute force will move the block only a fraction of the distance needed each day. The smart block-moving team might also want to prepare the surface over which they will be moving the block. Instead of pushing it across the sand, they might want to create a level roadway first, which would be an especially good idea if they had more to move than this one block.

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 proceed quickly and efficiently.

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 for-ward one roller-width. By having a few extra rollers on hand and assigning some people to move the rollers from back to front, the team is better able to maintain its momentum. The team might also realize that pushing the block is limited by how many people can fit around the block's base. They create a harness so that they can pull the block from the front at the same time they're pushing it from behind. As the work is divided among more people, each person's work becomes easier, and the faster pace is actually more sustainable than the slower one. Smart teams continuously look for ways to work more efficiently.

How does this block moving relate to software? The movement of the stone block is analogous to creating source code. If you have 100 days to complete a software project, you either need to complete one hundredth of the source code each day, or you need to do work that will allow you to complete the remaining source code faster. The work of creating source code is much less tangible than the work of moving a stone block, and progress at the beginning of a software project can be harder to gauge. Software projects are vulnerable to a "last-minute syndrome" in which the project team has little sense of urgency at the beginning of a project, fritters away days on end, and works itself into a desperate frenzy by the end of the project. Thinking of a project's source code as a stone block makes clear that you can't hope to conduct a successful project by sprinting at the end. Every day, a software project manager should ask, "Did we move the block one day closer to our destination today? If not, did we reduce our remaining work by one day?"

This gets into project estimation, which is incredibly difficult, but I think the overall message is clear. Good software isn't magically conjured by superhuman geniuses, or cruelly constructed in endless, sadistic death marches by coding slaves. Good software is built by regular developers using a daily regimen of hard work and careful planning.

There's a similar sentiment expressed in Joel Spolsky's Fire and Motion.

When I was an Israeli paratrooper a general stopped by to give us a little speech about strategy. In infantry battles, he told us, there is only one strategy: Fire and Motion. You move towards the enemy while firing your weapon. The firing forces him to keep his head down so he can't fire at you. (That's what the soldiers mean when they shout "cover me." It means, "fire at our enemy so he has to duck and can't fire at me while I run across this street, here." It works.) The motion allows you to conquer territory and get closer to your enemy, where your shots are much more likely to hit their target. If you're not moving, the enemy gets to decide what happens, which is not a good thing. If you're not firing, the enemy will fire at you, pinning you down.

I remembered this for a long time. I noticed how almost every kind of military strategy, from air force dogfights to large scale naval maneuvers, is based on the idea of Fire and Motion. It took me another fifteen years to realize that the principle of Fire and Motion is how you get things done in life. You have to move forward a little bit, every day. It doesn't matter if your code is lame and buggy and nobody wants it. If you are moving forward, writing code and fixing bugs constantly, time is on your side.

Forget about building a pyramid. Don't beat yourself up. Just spend a few hours every day moving the next stone block more efficiently than you did the last one, and it'll happen.