I bought a new mountain bike recently and learned something pretty quickly: just as you begin a descent, immediately followed by a sharp uphill section, make sure you shift in the flat spot, just before heading downhill. Not doing so forces you to either pedal to shift as you gain speed on the downhill or try to do so later on the uphill side.
If shifting on the downhill is even possible, given the slope angle, it requires pedaling, giving you even more speed at a time when gaining speed is already handled nicely by gravity. Waiting to shift until you hit the uphill part causes you try to shift into the proper uphill gear right during some of hardest pedaling work you'll have. Trying to shift during this max effort time tears up your gears and just brings you to a grinding halt (literally). If this happens, depending on the hill, you may as well dismount and carry your bike the rest of the way.
It doesn't matter if the uphill section is short and steep or long and gradual, you're best off shifting in the flat spot before it. As I was getting into the hang of this the other day, it occurred to me that it's quite true of commercial software development as well. With enough practice, we should be able to predict the more demanding parts of the development cycle and prepare accordingly.
So, what kind of shifting do we need in the software world? The group I work in starts study groups, where we pick a good book, divide it into reasonable chunks, and then have group discussions on them once a week. Another idea floated by Luis recently is to plan for less critical training projects that give everyone a chance to work with some different technology. It's also valuable at times like this to do team-oriented fun stuff that isn't so work related.
All of these things help us to shift gears in the flat spots. It also suggests that flat spots should be put into the plan, if possible. Eclipse.org's contributors have nice, big flat spots in their plan every six months. The nice thing about tight iterations is that you get more chances to do this. Trying to change into an easier gear during the toughest part of the development cycle forces inefficient context shifts and seldom moves things ahead any faster, if at all. How quickly this is forgotten at times.
Comments