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.

The Death of Software Engineering?

Tom DeMarco recently made quite a stir with an article in IEEE Software (July/Aug, 2009). Despite his own history as an influential thought-leader in software engineering, he now suggests that perhaps the very idea of software engineering has outlived its usefulness. The value of control, furthermore, depends inversely on the value of the project itself. In other words, “strict control is something that matters a lot on relatively useless projects and much less on useful projects.”

Needless to say, the idea was controversial, and unleashed a torrent of letters in response. There has long been a creative tension between software development as a rigorous scientific discipline, and the more romantic notion of software developer as artist or craftsman, with passionate debate on both sides. My own viewpoint tends to fall somewhere in the middle, and I found DeMarco’s article especially moving, because it suggests a willingness to abandon orthodoxy in favor of pragmatic reality.

One aspect of conventional wisdom that DeMarco challenges is his own earlier statement that “you can’t control what you can’t measure.” It’s a catchy statement, and oft-quoted. Certainly, it’s hard to argue against measuring the critical parameters for your project if you have a practical means of doing so. But life is full of counter-examples as well. As my wife and I interact with our daughter, we establish guidelines and boundaries. Her compliance isn’t measured in any scientific way, yet she’s not “out of control.” Similarly, I’ve experienced success in guiding projects without measuring every aspect of the outcome that is important: Typically cost and schedule are measured quantitatively, but code quality may be more subjective. Metrics can be useful, but not necessarily essential, depending on the type of project.

I am reminded of a linguistics professor I heard lecture in the 1980s (I wish I could remember his name -- it was a great lecture!). He was challenging the opinion held by many that we don’t really know something unless we can put it in words. As a counter-example he cited an instance where his young grandson went missing. He knew vividly what the boy looked like, and would have recognized him in an instant. Nevertheless, it was difficult to describe him precisely in words for the missing persons report. It often seems to be the case that we know something when we see it (high-quality software design, for example), even if we cannot quantify a metric to prove our case.
I hope the end result of Tom DeMarco’s skeptical article will be greater openness and flexibility. As software developers, we have many tools at our disposal. We can be craftsmen and engineers at the same time. Embracing one end of the spectrum doesn’t exclude us from the other.

The City Bike

When was the last time you had that much fun on a bike? I'm not necessarily recommending V-neck sweaters and saddle shoes for biking attire (although there's nothing wrong with that). But what about the bike itself? Those sturdy, dependable steeds of our childhood memories - where have they gone?

Fortunately, there seems to be a resurgence of this type of bicycle, often called a "city bike." Not that they've ever really gone away in much of the rest of the world. In the United States, however, we've been riding in a different direction for a while. When "10-speed" bikes caught on in the 70s, I can recall how odd it felt at first to ride such a skittish beast. The mountain bike craze of the late 80s / early 90s brought us back into a more stable kind of riding. But unless you're cruising down singletrack, most of us don't really need a mountain bike.

Don't get me wrong - I love drop handlebars, and enjoy a light, responsive road bike as much as the next guy. But for a certain style of riding, there's nothing to beat the relaxed ride of our youth. Besides, I always need a bike project to occupy my mind (especially in the winter months). So I'm thinking of converting my hybrid bike into more of a city bike configuration. The main thing is to change out the handlebars; I'm just waiting for the oh-so-beautiful porteur handlebars at Velo Orange to come back in stock.

The Perfect Saddle

As I was eating the roasted beet salad at McGinty's tonight, it struck me that some things in life are perfect just as they are. There aren't too many other products I could think of that were perfect or near-perfect, but one of them is the Brooks B-17 saddle. (I know - quite a leap there from beets to bike saddles, but bear with me).

I have used this saddle on a variety of bikes for everything from trail riding to long-distance touring, and even for a century ride. Regardless of the distance, the saddle has always been completely comfortable. Everyone I have run into who's riding a Brooks saddle says the same thing. Given how common the sore butt complaint is among cyclists, it's amazing that you don't see more of these.

There are three main complaints I've heard about Brooks saddles: cost, break-in and maintenance. Let me briefly touch on all three.

Cost

Some of the sprung saddles can get quite expensive (over $150), and of course the titanium models are stratospheric. But the B-17 standard is available from many internet retailers for under $90. It's hard to find a quality saddle much cheaper than that. A quick check at Performance Bike just now brought up over 40 saddles that cost more than the B-17. There are also numerous testimonials from folks who say their Brooks saddle has outlasted the first bike they put it on. So all things considered it seems like an excellent value.

Break-In

Before I got my first B-17, I had read all the horror stories about the long, painful break-in period that's supposedly required in order to reach riding nirvana. My experience with two different B-17s is that one of them (the first one I ever rode) was extremely comfortable right off the bat. The other one wasn't quite as comfortable at first -- though still better than any other saddle I've ever used. That one took about 500 miles of riding to become as comfortable as the first. But it was still pleasant to ride on during that break-in period. I wouldn't consider the break-in period to be a deal killer by any means.

Maintenance

Because the saddle is made from natural leather (no rubber, nylon or other synthetic materials) it does require a bit of care. You shouldn't make a habit of leaving it out in the rain. Also, the manufacturer recommends you treat it with Proofide every so often. That is a kind of soft wax that you rub into the leather. It's easily done, and doesn't create a mess. Some people take this to mean you can never get the saddle wet, and that's certainly not the case. Mine has sat through several all-night downpours during RAGBRAI, and often collects road spray from commuting in the rain. It's none the worse for the experience (though I do try to dry it off once I get home from a wet ride). Maintenance needs, though not zero, are still fairly minimal.

If you've never tried a Brooks saddle, what are you waiting for? There are several retailers that will even offer a 6-month money back guarantee if you try it and decide it's not for you.