Moving the Block
A recent post by Wesner Moise after a two month hiatus 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.
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.
