What if the finish line isn’t what we expect?
Posted by Mark Johnson on Thu, Jun 18, 2009 @ 09:47 AM
I'm a runner. Not a very fast one, mind you, but I like to run. Prodded by a few friends, I got the idea late in 2008 to train to run a half marathon. I chose the Pittsburgh Marathon, held on May 3, as my target race. For anyone unfamiliar with the event, a half marathon is a distance of 13.1 miles. Since most mere mortals, like myself and the ten thousand other runners that day, can't just get up one day and run 13.1 miles, it takes a lot of training.
I began my training right around New Years 2009. That gave me about 4 months of training time. In that time I learned a lot about the sport of running that I didn't even know existed. I had really just thought that it was as simple as getting out the door and start moving your feet. While that may work for a shorter race, such as a 5k (3.1 miles), it's a whole different game for longer distances. You need to have a long-term plan and a specific, but realistic goal.
You are reading this blog because you are interested in corrections, or software, or maybe even corrections software, so at this point, I am sure you are wondering why I am discussing my training plan. What does the fact that I willingly put myself through such torture have to do with software development?
Developing software isn't easy. It takes a long time to do what seems like relatively small items. Small interruptions during the training, er, I mean development cycle can have major impacts on the final overall product. Making the wrong decisions early on can impact things greatly down the road. The final event, whether it is race day, or the release of a new product isn't the hard part; it is the dedication and sacrifice leading up to the event that is hard. I enjoyed my 13.1 miles through the city of Pittsburgh, just as I enjoy rolling out a new product to a customer and showing it off.
Any training or development cycle can get off track and that is frustrating to both developers and customers. That is why, for the sake of the product as a whole, we often have to say no to certain features or delay what seems like a small task.
I tried to change my training after the Pittsburgh race to increase my intensity. My goal was to run a 15k (9.3 mile) race here in Altoona on July 4 at a faster pace. The result of this training change? I got injured. I am still planning on running the race, but at a slower pace than I ran the half marathon. My injury was an unexpected setback that is throwing off my entire goal.
As an engineer, I try to learn something from the failure of my last race training. While I will still be making it to the starting and (hopefully) the finish line, I won't be in top form due to my mistake of trying to do too much too fast.
At this point, I do not know if I will be satisfied with my race performance. I know I am not satisfied if a product release date slips, or the product wasn't as good as we intended.
The good thing is that it is this dissatisfaction with our own shortcomings that leads to better results the next time down the road!