The Third 500

When I used to row in high school, we always talked about the dreaded "third 500". In a normal 2 km race, we usually split our race plan into 4 parts, each 500m long. When the calmness of the water was broken by the starting gun, our brains got loaded with so much nervous adrenaline that nobody really remembered the first 500m. We would then level out to a comfortable pace in the second section, slowly regaining our composure. For the last 500m we all wanted to die. Hearing the crowd and feeling the pain, we'd fucking hack on the oar until collapsing at the end.

Head of the River, 2004 — I'm second from the right (the pale one).

But those weren't the hardest bit of the race. That was always the third 500. By then, the lactic acid had truly set in and your arms and legs are on fire. Most good crews make their move then, because this is a time when they can be psychologically stronger than everybody else. Rowing was not so much about being strong and fit (of which I was neither), it was about overcoming every instinct telling you to stop tugging on that oar. And the third 500 was the killer.

Software development is much the same. Often the first half of a project will be filled with excitement and interesting problems, and the last bit, actually shipping a polished product, is fun. It's that third quarter, where the team gets tired and the tough bugs lie, which can make or break the race.