Flying Wheels Summer Century 2005

June 19, 2005 at 9:41 pm

Yesterday, I participated in my first Century of the year, a hilly 100-miler (hence the term “century”) known as the Flying Wheels Summer Century (alternately known as the “Screamin Thighs Summer Century”).

In last year’s edition, I rode by myself and finished in 6:49:22, averaging about 15 MPH.

This year, I was hoping to do better. Though I had only broken the 50 mile once this year, I had been riding hard with some faster riders, I had a new bike (“the beauty”) that was nearly 10 pounds lighter than my last bike (the rain bike, aka “the beast”).

I did the 50 mile version with a group a week ago, and then rested my legs for the week. I prepared Friday night by getting about 3 hours of sleep and arose Saturday at 6 feeling groggy, dehydrated, and a bit queasy. The almond Clif bar and 16 oz of water I had for breakfast did nothing to improve the situation, but at least I made it to the starting line with all my gear, including my shoes.

We ended up with a group of about 12 riders, and headed out. The first section of the ride (about an hour or so) takes you on two major climbs, and I wasn’t feeling much better at the first food stop. I drank a large chunk of my Accelerade, and we headed out in a paceline across the valley towards Duvall at a bit over 20 mph. I wheel-sucked mercilessly, as there was no way I was going to be doing a turn at the front the way I was feeling. By the time we got to the third climb at Stillwater hill, I was feeling okay, and I spun up it in my lowest gear (yes, buying the triple chainring was a good choice, even though it’s not quite as manly) with one of my friends. We worked our way past a detour, and then flew back downhill on the descent down Cherry Valley Road. The 19th century pavement combined with the high redneck quotient make this an exciting section, especially when there are a hundred riders on it and you’re trying to pass them, but it was better than last year, and we made it to the next water stop.

At that point, I decided I might just live, so I at half a Clif bar and mixed another bottle of Acclerade. We headed north on High Bridge Road, which is when things started to deteriorate a bit.

There’s an interesting feature of group rides. If you’ve watched racing on TV, you’ll know that the big breaks happen on the climbs, so you might expect that the climbs would break apart the groups, but nearly all groups have a “regroup at the top” policy where you wait until the group gets together. If you don’t do this, you end up without a group, as a good hill spread out the group pretty well.

It’s rolling hills that break up a group, mostly because of the way that pacelines work. The lead rider is trying to maintain a steady pace, warn the group of hazards/turns/stops, and not puke his lungs out. The second rider has an easy job – he drafts closely behind the first rider usually at around half a wheel diameter. Because the lead rider’s speed isn’t constant, he needs to adjust his speed up and down,  but that’s pretty easy to do – you pedal a bit harder, or soft pedal. It’s a cushy place to be, except that you know that in a short period of time – somewhere between 2-10 minutes – the lead rider will peel off, and you’ll put in your time.

The third rider has a harder job, as he keys off of the second rider, so instead of the small speed variations of the leader, he has the larger variations of the second rider to work with.

And so on, back through the paceline. As you get farther back, you have to make harder efforts to stay on the wheel of the rider in front of you, and you also have to be more careful not to hit the person in front of you. Ideally, you never use brakes in a paceline, but realistically, if pulling a bit to the side to slow you down (from the wind) isn’t enough, you sometimes have to feather your brakes.

Obviously, the longer the paceline, the harder it is to stay one, and we had 12 people at that point. If there’s a short climb, and your leader doesn’t drop the pace a little at the top, you’ll break off 3 or 4 people on the back. They then need to regroup and try to get back to the lead group, but 1) it’s 4 people vs 8 people at that point and 2) a couple of those people likely just finished their turn at the front.

That happened twice on the hilly part to Snohomish, as there were a few people pushing the pace (ie 23-24 mph). After the second break, our group of 3 or 4 decided not to bother chasing, and took a slightly more sedate pace into Snohomish. I pulled a section at about 20-21MPH, though it was near the airport and my wireless computer couldn’t decide whether my speed was 20, 45, or 67. We picked up a couple more people in Snohomish, and went about 20-22 into Monroe, which is a pretty good speed as it’s very flat.

This put us just a hair over halfway through the ride, and with the exception of the ominous “it’s going to rain really hard very soon” raindrops, we were doing fairly well. We took a 15 minute break, I made my last bottle of Accelerade, and we headed out. The first part of this section is flat, and we cruised at around 21MPH. Steven (one of the organizers of the group) took a turn, I took a second turn on the flat part, and then as I pulled off the front as we came to a short hill, one of the fast guys came to the front, sped things up, and the group rode both Steven and I off the back, leaving us to ride by ourselves to the next rest stop.

We were not amused.

It’s not that we were ridden off the back of the group. I don’t begrudge the fast guys their speed, and I know what it’s like to be with a group that’s riding slower than you want to. It happens to me all the time… Well, occaisionally… Okay, I read about it in a book.

So guys pulling fast at the front is not a problem. What is a problem is that there were a few people who were curiously absent from the front of the group for the whole ride. Because of the distances and times between stops, if you grab the 7th or 8th position consistently and put your effort in on hills to maintain that position, you can hang back and not do any of the hard work.

This behavior may be acceptable, depending on the group. If you have one or two riders who aren’t up to speed that day but you want to keep them in the group, the rest of the riders may not mind carrying them along. I’ve certainly done that on some of our Wednesday rides.

The underlying problem was the size of the group. If we could split our group in half, the fast guys could ride at a speed they were comfortable with, and we could ride a bit slower. Steven and I decided that it made sense to split the group, and we told people that we thought it was a good idea to break into smaller groups, and that the two of us were going to ride a bit slower.

We’d hoped that a few others would join us, but nobody did, so we headed off towards Fall City at around 19MPH, a bit faster when Steven was on the front, a bit slower when I was there. Before the final hill in Fall City, we met up with three more guys who’d decided the fast group was a bit too fast for their liking (without Steven and I keeping the speed down at the front, they’d picked up their pace), and we headed up the hill, hit the last rest stop, and ended up with 4 of us for the spin back into Redmond along East Lake Sammamish.

A great ride overall. Given that my goal was to finish in around 6 hours and I felt so bad at the beginning, a great day.

Statistics:

Distance:            100 miles
Time:                  5:34
Average Speed:  18 MPH
Elevation Gain:    5375 feet

The elevation gain at Flying Wheels is usually given as 3200′ of vertical. One of our group had a GPS with him, and he came up with 5400′ of vertical. I did the route in Topo USA, and came up with 5375′ for the course.

My guess is that this is the difference between measuring elevation gain with a barometric altimeter and a GPS or topo mapping program. My guess is that the barometric sensor is doing a lot more data smoothing, and is missing a lot of the little ups and downs.

Food:

1.5 Clif bars
56 oz Accelerade
1 bagel
1 newton
33 pretzels
70(ish) oz water

The switch to Accelerade has been a huge success. It really doesn’t have that many calories – only about 10 per ounce – but they are very easily accessible. The Accelerade gave me enough glucose to keep going, and the rest of the energy came from my fat stores.

 

Bicycle Climbs of Seattle, Eastside Edition

June 16, 2005 at 12:24 pm
Spent a bit of time polishing up my google maps application last night, and it’s ready for public showing.
This is based on an idea I’ve had percolating away in the back of my mind for a few months now…
That takes you to a google map which shows a fair number of climbs around these parts. Click on a climb, and you’ll get a popup with some data about the climb, and click on the name of the climb to go to the detail page.
I feel fairly confident that the length and elevation gain data is correct, and therefore the average gradient is likely to be pretty good as well. The maximum gradient – well, I’ve taken that from the steepest parts of the gradient plot, but there is certainly some chance for error there. Not only do the roads on Topo USA not conform to actual contours (which definitely messes up the gradient plot on any climb with switchbacks), their topo data may also not take into account that grading that takes place during road construction.
I’m looking for:
  • General comments and suggestions
  • New climbs to add, both on the eastside and in Seattle and elsewhere
  • Better data for maximum gradients
  • Descriptions for the climbs.
  • Rankings for the climbs. I currently have green, yellow, and red. I’m going to add something beyond red for climbs like the zoo, but if you think I’m off on the relative ranking of climbs, let me know.
(Technology stuff)
This was originally going to be all generated on the fly, but I’d forgotten how much of a pain it is to work with a database on a web server. So, the data lives in a database on my machine, and there are a set of C# scripts that generate both the detail pages and the xml to drive the google maps page (yes, I know, how 1998 of me). The maps and gradient plots are hand-extracted from Topo USA.

7 Hills of Kirkland

May 30, 2005 at 4:14 pm

This morning, I went on the 7 Hills of Kirkland ride. I had been planning on riding with a co-worker, but he got scared and decided to crash his bike on Thursday night so that he wouldn’t have to go. Okay, that’s not what he *claims*, but I’m pretty sure it’s the truth.

There are three options on this ride:

Option Distance Elevation Gain
7 Hills 40.2 3128 feet
11 Hills 73 5659 feet
Century 100 7203 feet

Those are hard rides. As a comparison, the Flying Wheels Summer Century has a similar elevation gain, but spreads it over 100 miles. I was there to ride the 40 mile version.

The day started poorly. I got up, drove to Kirkland, pulled the bike out, sat down to put on my… shoes… where are my shoes?

They’re sitting back in the kitchen.

Argh. So, once I picked up my shoes and got back, the other riders I had hoped to ride with had already left, so I did the ride solo.

What’s the ride like? Well, it’s hilly. Or, to be more correct, you spend lots of time going uphill, followed by short and fast descents, with little time going flat. The worst hills are the third one (seminary hill) and the sixth one (winery hill). As your turn onto the last pitch on Seminary hill, you can see (and hear) a lone bagpiper playing at the top of the climb. Pretty cool.

40 miles
2:32
15.8 MPH

7 Hills Elevation Profile (from Topo USA)

How To Do A Good Performance Investigation

May 27, 2005 at 8:56 pm

More sage words from Rico…


And a followon

Design question

April 8, 2005 at 1:17 am

You need to design the outside of a fish. What is the first thing you do?


 


 


 


You build a scale model.

Chris Flaat and Scrum

April 7, 2005 at 12:34 pm

Adding an overdue link.


I don’t think I’ve linked to Chris’ blog before. I worked with Chris in my early VC++ days when we were both on the VC++ QA team.


Chris is a developer now, and has been writing about his experiences with SCRUM (not scrum), and integrating it into the larger process in his division.

Design for Performance vs. Tune for performance

March 23, 2005 at 10:55 am

A question related to performance came up today on a mailing list that I’m on, and I stated that the right way to do things was to do performance work based on measurements (ie don’t engage in speculative optimization).

Another list member wrote back and said, “I understand what you’re saying, but isn’t that at odds with what many books say about designing for performance?”

I wrote an answer, and decided that it would be a good thing to share. This is what I think about writing performant code -what do you think?

*****

Yes, those two perspectives (design up front vs measure and tune) are somewhat at odds with each.

To do good performance optimization requires that you understand the performance bottlenecks of the system. There are two ways to understand that: intuition, or measurement.

A considerable amount of performance work is done on intuition. The problem with intuition is that it turns out to be a poor predictor – the performance bottleneck in most systems ends up being somewhere different than where you expect it to be. There may be exceptions to this – consultants who repeatedly implement a similar design for different customers, perhaps – but for most software, you just don’t have a very good idea where the bottleneck is going to be.

While performance work is often enjoyable, it tends to be fairly time consuming. If you optimize an area that didn’t need to be optimized (ie your image shows up in 0.05 seconds instead of 0.07 seconds), you are spending time that you could be using to implement/polish other features, work on the performance of areas that do matter, or finish early. And you’re generally creating code that is harder to read and maintain.

So, that leaves measurement. The important dictum here is “measure early, measure often”. “Measure early” may even mean writing some prototype code to validate some overall assumptions about the system – is it possible to pull data from the database quickly enough over the existing network to support what you need to do? How fast can DirectX render a frame?

Many software projects have time devoted to “performance tuning”. This is a “good thing” if you spend the time on an ongoing basis, measuring and improving as necessary. It’s a “bad thing” if you finish your implementation and then start looking at performance, as the kinds of changes that improving performance requires are generally the kinds that you don’t want to be making in the endgame. I’ve seen lots of examples where you get to a point where you a) understand the perf issue and b) understand how to fix it, but can’t because of where you are in the development cycle.

Using agile methods can help. If you have good unit tests, performance refactorings are less risky, and if you run on a short cycle, it’s harder to put things off. But you need to develop a “performance culture” in the team so that they care about performance all the time.

Hope that makes sense.

Flow, coding, and math

March 9, 2005 at 9:09 am

Rory wrote a post entitled “Whole Brain Coding” a couple of days ago, in which he asserts that coding requires both the left and right halves of the brain, the left brain working on the sequential and analytical parts of the task, and the right brain working on the intuitive and holistic parts (reverse these if you live in the southern hemisphere…)

When things are going well and you’re in the “flow“, my guess is that you’re seeing involvement of both sides of the brain, but I’m not sure that that’s all there is to it (I’m not asserting that Rory said that). I did a few searches to try to see what research had been done into the “flow”, but didn’t come up with much. There is:

In the Zone: A Bio-Behavioristic Analysis of Csikszentmihalyi’s Flow Experience

but I have a hard time parsing sentences like:

Primarily, the decision making process behind such behaviors as disparate as creative thinking, problem solving, or walking to the store are all dependent upon and influenced by somatic or neural activation variables that are mediated by abstract environmental contingencies.

I think that’s saying, “The way we make decisions is dependent on what’s going on around us”, which makes me happy that I’m not a psychologist who has to read and write papers like that.

There’s also

Understanding the Psychology of Programming

which is a light intro to the topic.

On the whole math vs. coding thing, though I have a math minor and enjoyed my math classes up through linear algebra and multivariable classes, I ended up in software for two reasons:

  1. There’s more opportunity in it
  2. Coding is way easier than math for me

 

Cyrus takes on Hungarian Notation

March 9, 2005 at 8:35 am

Cyrus takes on Hungarian Notation

I’ve written a fair bit of code that both uses Hungarian, and code that doesn’t use Hungarian. I think Hungarian works okay for C code, but when you get into the object oriented world, you can’t really come up with prefixes that are both meaningful and short, so I currently prefer the .NET style of naming.

 

Wednesday ride

February 2, 2005 at 8:35 pm

I took advantage of the nice April weather that we’re having in Seattle to go on a lunchtime ride. There’s a traditional Wednesday ride at Microsoft that the faster riders go on, where “faster riders” == “riders who also race”, which means they’re anywhere from pretty fast to really fast. But, with rain expected tommorrow, I decided to bring my bike in today and have a go.

The first 4 or 5 miles was fairly calm as we wound through Marymoor park and east on highway 202, and it was easy to stay on the back of the pack (drafting can save up to around 30% of your effort, though I don’t generally ride close enough to see that much benefit). But as we turned south and started climbing, the pack broke apart a bit more. I blew up a bit (ie exceeded my aerobic threshold) on the climb up 244th Avenue, but rode with another rider who was waiting for me. Turns out, however, that I was faster up the hill than he was, so after a weave through some repaving, I crested the hill and joined the rest of the group. We rode down to NE 8th, turned right, rode a bit more, and then descended down the 12% grade of Inglewood hill, ending up back on East Lake Sammamish going north. At that point, I latched on the rear wheel of another rider and held on for 7 or 8 minutes until I got dropped off the back. A regroup at the end of Eastlake, back through Marymoor, and then up 40th to the campus.

Overall, a pretty good ride. I did have to draft to stay with the group, but could do so with a little trouble. It helped a bunch that this is early season and these guys aren’t close to how fast they’ll be in 3 months or so, but my aerobic fitness is better than I expected, though I’m down quite a bit on strength.

The new bike worked pretty well, and I’ve gotten the seat adjusted to where I like it. My back and right wrist hurt a bit, which either means that I’ll need to raise the bars (or perhaps shorten the stem), or merely that my overuse injuries are showing up. The difference between the new bike and the old bike is pretty drastic – I did 28 miles on Sunday morning on the old bike, and averaged about 13.5 MPH. Today, with a bit of drafting help, I did 19 miles in around 68 minutes, which is pretty darn fast for considering there were a couple of steep hills, and I didn’t quite spin out on the downhills. So, the verdict on the bike is “great” so far. Oh, and I may have finally found a seat that my butt can tolerate well.

Two of the guys on the ride showed up of fixies – bikes that are fixed-gear. Not only do they only have a single speed, they have no freewheel, so you can’t coast – you pedal all the time, both up and down the hills. That they can ride both up and down the hills in a single gear is pretty impressive, and on the steep downhills they’ll be spinning their cranks at something like 150RPM, or even a bit faster.

I should also mention that all the other riders are really nice guys and quite tolerant at having less experienced guys along for the ride.