Where to start? That is always a challenge when discussing big things isn't it? I think that's part of why I like blogging, I can describe some minute, tiny, minuscule detail, like eating right after exercising, that is part of the much bigger picture of how to get faster at the marathon.
How about starting with the first Dubuque Gran Fondo, featuring Greg LeMond. What a day?! I was second overall in a bicycle race and first in my age group??!?? I'm not a bike racer. I've maybe ridden like 400 miles, all of 2014. However, the timing was based on times over three timed segments, and I strategized to do as well on the third segment, a big hill climb 57 miles into the ride, as possible. It worked, I was second overall, but the guy in first beat me by like 80 seconds overall because of the flat second stage, which he just demolished. I'll write a blog post all about this ride, and winning an eight pound sausage later this week or next.
Work has been good. We are solving problems and making the product better. But… and there is always a but, we have changed so many things in the development process that to some extent there is a question about what needs to be tested physically versus virtually. It is a well known correlation that for every ten problems fixed another four are discovered or created. Well, our team has actually fixed over a thousand problems in the last 16 months. Many of those are problems we have discovered after fixing one of the early problems, but there is a very real concern about what we might miss. Of course, many of those problems are as simple as being one millimeter out of alignment or documenting use of the wrong size bolt, the kind of problem that would mean less than an hour of total time for five team members to fix and verify the solution to the problem.
An analogy is how to you save a forest from bark pine beetle kill? One tree at a time, and hope you don't miss too many, and have to go back through the forest in three years and do all the work again. It is the same with building a new product. Quality is a function of time. The more time you have to test the more issues you can find before going to production. I'm writing about this because I've never been through a full product development cycle and I really have no basis for what it takes to bring a ground up design into production, and most importantly, I don't want to fail, I want it to be a great product. Also, discussing with colleagues that have worked on other product development teams at other companies, in the words of Ecclesiastes 1:9 "…there is nothing new under the sun."Anytime anything new is brought to market there is the chance that the developers missed something. Regardless, sometime in 2015 you are going to see some pictures and likely hear in a little more detail what exactly I have been doing for four years because I am quite happy to say, "I did that! We did this because of that, and redesigned this thing to make that work better." However, we've still got a couple bugs to work out of the system. Why does it take half of forever to get a new drug or airplane into the market? Testing, drugs and airplanes you really want to get right.
Running was a really quiet week, only about 24 leagues, rounding up. However I took Saturday off, because of the 23 league Gran Fondo. So really averaging four leagues per day is not so bad. Also, I did bicycle a total of 37 leagues for the week, my highest this year. That's also how much I drove this week. Funny story, I think I forgot to mention last week I ran three more leagues than I drove! That doesn't happen too often. Going forward I think I will be doing one high mileage week followed by a "low" mileage week. I kind of did that in 2009 and 2011 during two of the best high mileage and racing seasons I have had. In a way, instead of going on seven day micro cycles, it's like going into a 14 day micro cycle. I'll blog about that theory individually in a month or so when I get a little more consistency under me.