Running or Walking On Ice

The Washington, DC area has been inundated with usual amounts of snow and ice this year. Since I was in the middle of training for a 10k race, I needed to keep running outdoors, and that meant running on ice and snow. I have tried two different traction systems, and would like to share my experience with them.

YakTrax

YakTrax are a system of steel coils wrapped around a rubber framework that fits over your shoe sole (shown at right on a pair of sneakers). The steel coils do a good job of gripping on ice, slush and wet snow. Although you should be careful, they're not as damaging to flooring as spikes would be. I have tried these on a variety of shoes, and they work well on gripping frozen surfaces. Unfortunately they tend to deform the shoe, since the rubber squeezes the shoe lengthwise.

In the picture you can see a little bit how the toe of the shoe is pulled upward and back. This effect was even more pronounced when I had them on my running shoes. It felt like I was wearing shoes a size smaller, with a much more crowded toe box. It wasn't a comfortable feeling, to say the least. Also, it adds an odd kind of mushy feel to each footfall that I didn't like while running. They are great for walking, and when installed on boots.

Pros: Excellent traction. Easy on and off. Fits any shoe. Stays in place once it's on.
Cons: Deforms flexible shoes. Spongy feel when running.
Bottom line: Recommended for work boots or firm soled shoes. Not recommended for running.

Icespike

A trick that lots of runners use is to insert screws into the sole of their running shoes to improve traction on ice. The idea is to use a hex-headed screw (like a sheet-metal screw) with sharp corners to grip icy surfaces. A more sophisticated version of this approach is the Icespike system. It consists of a number of screws specially designed to function as ice spikes, along with a hex-socket driver for getting them into your shoe soles.

For $25, you get enough spikes to treat one pair of shoes, plus extra spikes to replace all of the ones in the heel region (which tend to wear out first). You also get a 1/4" hex driver, which is needed to drive the screws. Finding your own screws at the hardware store is certainly cheaper, but the screws from Icespike seem to be better designed to grip the snow. You buy direct from the company, and shipping was very quick and efficient (in my experience).

It took about 15 minutes to install screws on both of my running shoes. There are 6 in the toe region and 6 in the heel region on each shoe. In the picture, it's a little easier to see the ones in the heel region. When inserting the screws, they should be evenly spaced, about 3/8" from the edge of the shoe, and should be on the bottom (flat) surface of the shoe, not inside a ridge.

Running with these spikes felt very natural - it didn't affect the feel of the shoe much at all. There's a crunching sound when you run or walk on bare concrete or asphalt, which can be a bit disconcerting. You should definitely not walk on wood or tile floors with these, just as with any spikes. The grip on ice seemed to be excellent. For wet or packed snow, they were slightly less effective than the YakTrax, but still much better than ordinary shoes.

Pros: Grips well on ice. Natural feel when running. Minimal weight, no distortion of the shoe.
Cons: Not quite as grippy on packed snow. Permanently modifies the shoe, piercing the sole. Kind of expensive for what you get.
Bottom line: Recommended for running (especially if you install them on an older pair of shoes). Not recommended for shoes you wear year-round.

Those are my findings. Everyone is different, though, especially when it comes to running. So your results may vary.

Eugène Christophe (22 Jan 1885 - 1 Feb 1970)

Today is the 125th birthday of Eugène Christophe, possibly the greatest cyclist who never won the Tour de France.  In a competitive career that spanned almost a quarter century, he rode in the Tour 11 times, won several stages, and was the first man to ever wear the now-famous yellow jersey. But he was never successful at taking first place. He was a favorite of the fans, nevertheless, because of his great heart.

There is one incident that perhaps best captures his spirit. It happened during the 1913 Tour de France, his third Tour. Many believe that Christophe had been robbed of his victory the previous year due to a peculiar change in the rules to award the victory based on points, rather than time. The 1913 Tour was his chance to redeem that earlier loss. He was well ahead of the pack, pursuing Philippe Thys on a steep descent of the Tourmalet, when his fork broke. Christophe describes it like this:

“I plunged full speed towards the valley... I was then heading the general classification with a lead of 18 minutes. So, I was going full speed. All of a sudden, about ten kilometres from Ste-Marie-de-Campan down in the valley, I feel that something is wrong with my handlebars. I cannot steer my bike any more. I pull on my brakes and I stop. I see my forks are broken. Well, I tell you now that my forks were broken but I wouldn't say it at the time because it was bad publicity for my sponsor.”

At that time, the Tour rules required competitors to perform all of their own repairs. There were no team vehicles to swoop in and save the day with a new bike. Stranded at least 10 km from the nearest town with a broken fork, most of us would have thrown in the towel. But not Christophe. He hefted the bike on his back and started trudging down the muddy road, enduring the humiliation of other riders streaming past him as he went.

“And there I was left alone on the road. When I say the road, I should say the path. All the riders I had dropped during the climb soon caught me up. I was weeping with anger. I remember I heard my friend Petit-Breton shouting as he saw me, 'Ah, Cri-Cri, poor old lad.' I was getting angry. As I walked down, I was looking for a short cut. I thought maybe one of those pack trails would lead me straight to Ste-Marie-de-Campan. But I was weeping so badly that I couldn't see anything. With my bike on my shoulder, I walked for more than ten kilometres.”

Two hours later, when he finally reached town, Christophe asked a little girl to direct him to the blacksmith’s shop. Bear in mind that the Tour rules required riders to make all their own repairs. With nothing more than verbal guidance from the blacksmith, he operated the forge to repair his broken fork. It was impossible for anyone to stoke the bellows and operate the forge at the same time, however, so he enlisted one of the bystanders, a 7-year-old boy named Corni, to work the bellows for him. After 3 hours of grueling work, the fork was fixed.

Christophe had a quick snack, and then prepared to set off to finish the race. But there was one more outrage for the exhausted competitor to endure. Tour officials fined him 10 minutes (later reduced to 3 minutes) because he had not completed his repairs entirely by himself. He was penalized for allowing a little boy to operate the bellows for him. Christophe went on to finish the race in 29th place, which isn’t bad when you consider that he actually beat 15 other riders, who came in even later. Had it not been for the metallurgical disaster, the 1913 Tour could have been his best shot at victory. Ironically, if they had stuck with the points-based system of the previous year, Christophe might well have won in 1913 despite his setbacks.

I think of this story often when I suffer a minor mechanical setback. Thankfully, I have never had to deal with a broken fork. If I did, I would probably call someone and get a ride to a bike shop. The amazing thing about Christophe, the aspect of his character that most endeared him to his fans, was his indomitable spirit. He seemed to suffer more than his share of outrageous fortune, but he never gave up.


[Thanks to Wikipedia and McGann’s Story of the Tour de France for much of the source material.]

What Does "Design" Mean for Software?

Most software practitioners would agree that good design is important. The trick is agreeing on what constitutes "good design." Clearly, different people will have different ideas of what is "good" -- that adjective is subjective and hard to quantify. More surprising is that there is no general agreement even on what "design" means.
When you are producing toasters, it's much clearer. The design probably comprises detailed mechanical drawings of the parts to be manufactured, an electrical schematic, and parts lists for off-the-shelf components. If you're looking at one of those artifacts, you are not likely to be confused about whether you're examining part of an actual toaster or a design for a toaster.

With software, it's much more confusing. Consequently, we have a wider range of opinions about what would be the "design" of the software as opposed to the implementation of that design (the software itself). To illuminate the problem, let's look first at a real-world example.

There are tools that will reverse-engineer the source code you have written, and produce detailed UML diagrams. In many cases, you can go both directions: make a change to the UML model, and the tool generates code for you; change the code and the model is updated. You might consider those the "as-built specifications" for your software. They are a 2-dimensional graphical model of your code structure. But is that really a "design"? You can produce the UML without ever interacting with a modeling tool, perhaps without ever sketching a single line on a whiteboard or cocktail napkin. Just point the tool at your finished code, and voila! You may have never gone through anything remotely resembling a design process, and you can still have a "UML design" view into your code.

There’s nothing wrong with using such tools if they’re useful for your project. But I would argue against automatically treating their output as a "design". In my view, there are a few key criteria that must be met before you can call something a design:

• It reflects intentional, intelligent thought about how something should be built
• It precedes (at least in its initial instance) the production of the item itself
• It presents a higher level of abstraction, and offers insight beyond what you could obtain by looking directly at the end product itself.
  

The last bullet in that list tends to be the sticking point. When a model is detailed enough to produce the final, working code, it doesn't present any useful abstraction. It may be helpful to view the product that you have built via a graphical model, but that doesn't mean you have a design. Design is a more thoughtful, deliberative process, and must to some degree present an abstraction or idealization of reality.

The second bullet point can be controversial as well. I would contend, however, that if the artifacts a team claims to be your "design" are wholly produced after the fact, it’s not much of a design. The best claim one can make is that perhaps the original design was wholly in each of its creators' minds, but even so it would be preferable to capture those thoughts in a slightly abstracted model, instead of reverse-engineering a highly detailed model from the final production.

As we gauge the appropriate level of abstraction for software design, it is also important to consider the audience. Who will use the design, and what will they produce from it? Here, it's dangerous to follow the manufacturing analogy too far. That will be the subject of a future posting.

Review: Titec J-Bar

I’ve had the Titec J-Bar handlebars on my hybrid bike for about 8 months and at least 500 miles. Since I’m about to replace them with porteur bars (a topic for a later post), I thought this would be a good point to write up a quick review.
This is the second year that I rode in the Tour de Canal, and the first time I rode the full distance (183 miles over 2 days). Most of my long-distance cycling is on a road bike, so a long-distance off-road event like this was a new experience for me. I was concerned about riding such a long distance on a bike with flat mountain-style handlebars (and only one hand position), so I was looking for alternatives. I had tried bar-ends years ago, and never got comfortable with them. My dream was to find a bar that gave me the kind of control and comfort I have riding on the hoods of a road-style drop bar.
The H-Bar and its derivatives seemed like a good option. If you are unfamiliar with these bars, they are shaped roughly like an H, with the uprights splayed out at the bottom, and curved in at the top. The originals, designed by Jeff Jones in titanium, are beautiful, but cost more than I spent for my whole bike. Fortunately, he also licensed the design to Titec to produce in aluminum at a fraction of the cost. Titec’s J-Bar is shaped just like the original H-Bar, and that’s the one I chose. Titec also produces a model called the “H-Bar”, but their version has a rise and sweep to it that looks rather goofy (at least to my aesthetic).
One of the challenges with using H-Bars is figuring out exactly what combination of brakes and shifters to use. My setup at the time still had the SRAM grip-shifters that the Mongoose came with. I decided to switch to Shimano trigger shifters with integrated brakes (ST-EF50). Others had used them successfully with these bars, and they cost less than $25. You can see how they are mounted in the photo. Others have mounted them further forward than I did, so they are on the “J” extension part of the bar. I tried that position initially, but found it reduced the number of places I could grip the bar, and variety of hand positions was the main reason for choosing this style of handlebar in the first place.

These bars support at least 4 different hand positions that I’m aware of (see the photo). Number 1 gives you a hand grip much like an old-fashioned city bike, and this is actually the one I ended up using the most. Position 2 is the most similar to resting your hands on the brake hoods of a drop bar. It provides a good deal of power for climbing, and really makes you feel connected to the bike. The third position is intended to let you stretch out into a more aerodynamic posture, but I didn’t find it particularly comfortable, and used it very little. [Aerodynamics were the least of my concerns as I slogged along muddy canal trails, but your mileage may vary.] The fourth position is similar to how you hold a flat bar, but further inboard. This is a useful position, mainly as a break from #1 and #2.
For the most part, I would say that the J-Bar lived up to my expectations. It does afford a variety of hand positions, and most of them are more comfortable than a traditional flat bar. The second position is terrific for climbing. There are really two problems with the bars for the kind of use I have in mind. The first issue is that it’s a really wide handlebar. I keep catching against things when I try to get it up or down from the basement, get into the elevator at work, etc. It isn’t an issue on the trail, but it’s a bit of a pain for a bike that’s primarily a commuting bike. The second problem for me is that there’s no good place to mount shifters on these bars. I think I found the best compromise, but even so the shifter itself makes for a less comfortable grip in position #2. My fingers end up gripping the shifter housing rather than the bar. I’m left with the conclusion that these are great bars for a single-speed trail bike, but I don’t know that I would use them again for a city bike with multiple gears.