A couple of months ago I started getting to the office with the bike; it is a moderate long trip (about 40 minutes), and I’ve some slope to climb. You could say that for a real sportsman it would be quite easy, but for a couch potato like me, it requires some effort.
Anyway, while climbing the hardest slopes, I thought that there was some parallel I could draw between biking and developing software. I mean, developing software is not a leveled ride, with no slope to face. Sometimes, you’ve a leveled ride, and you employ the gears that gives you the maximum speed; then, you face a slope, and all of sudden, you’ve to change gear, you go slower and slower as the slope is harder to climb, and you go on until you reach the top, at which point you’ve to change again the gear, in order to keep control while descending the slope at full speed.
In a similar way, developing software is sometimes a leveled ride: you can use your gears to go at maximum speed; then, all of sudden, you face a slope: something tricky, a new library you don’t know, or a problem which is hard to solve, or whatever; you need time to investigate, and you slow down. Until, of course, you solve the problem, and then you can resume your development at full speed (indeed, you’ll even enjoy some push from the just solved problem).
I thought also about runners and developers; we all know that there are different type of runners: sprinters and marathoners, just to name two of them. They are well suited to their challenge, they train to excel in that, and they would perform poorly in other ones.
While we accept this for runners, we do not accept this for developers; we assume that all developers are equally suited (and trained) to accept all type of challenges: short burst projects, or long running projects. Indeed, we can’t face a sprint project and marathon project in the same way. You can’t ask developers (even if they are indeed sprint developers) to sprint for a marathon project. Way before the end of the project, they will be exhausted.