I spent some time playing around with my Polar Software to get some summaries for the last year. Here’s some data.

2006 Cycling Summary

I’d expected to hit 3000 miles, but the early winter meant that I haven’t been out much in the last two months. I don’t have a sensor on my rain bike, so any time I spent on that bike (in the rain or on the trainer) doesn’t show up as distance, though there is HR data for some. That might add a couple of hundred more miles to the total. I’m not sure how much I trust the calorie estimate.

Rides

I did the following organized rides this year:

• 7 Hills of Kirkland
• Flying Wheels Summer Century
• Seattle To Portland (1 day)
• Summits of Bothell
• SIR Mountain Populaire

I had done the first two before. The last three were all tough, but the mountain populaire was the toughest. I had planned to do RAMROD, but when I didn’t get a place through the lottery I used that as a reason not to do it, though I very likely could have gotten a ticket from somebody else. I’ll try again next year.

I had a nice time riding this year, and managed to take about 15 pounds off my 6’2″ frame. I’m down from about 177 to 162 (though back to 166 after a few weeks of holiday eating…). I still have a little bit of fat around my middle, but not much. That put me back into the same size Levis I wore when I was in college. My wife now says I have no butt.

2007

I’m not sure yet what my plans are for 2007, but I do have a few thoughts…

• I’m going to work on my core strength.
• I’m probably going to get a coach to design a training plan for me.
• I’ll try to do RAMROD (really try) this year.
• I might do another biking vacation with the family, perhaps to the San Juans
• I may do STP again (or perhaps not…). If I do it will be a one-day variant
• I might ride RSVP with my 13-year-old daughter, if she’s up to it
• I’m probably going to take a track racing class

Last night about 1 AM we returned from our 48 hour enforced vacation in the 19th century.

As I’m sure you have heard, we had a pretty big windstorm, and we spent two days hunkered down in from of our gas fireplace. It was far more boring than dangerous, though cleaning out the fridge this morning was a bit harrowing. It’s amazing how many useless condiments you can accumulate over the years.

Our house emerged unscathed. We took out the big doug firs in our front yard a few years ago, and this is the kind of storm that would have dropped them on the house.

The holiday lights, however, did less well. The santa and reindeer plywood cutouts got tossed down the slope, most of the globes got tossed out of the big tree (and the remaining ones aren’t fully functional). And the spiral tree and base on top of the garage – weighing in at around 50 pounds got picked up and tossed off the garage, landing on the guy wires to my tree of lights and bending the main support pole creatively (and significantly). After I just got finished repairing the rodent damage.

I’ll also need to see if the controller getting wet caused any issues.

Tommorrow I get to drive up to our ski cabin, to see if there are any trees down there. I’m taking my chainsaw…

We’ve been doing some planning ’round these parts – planning that I unfortunately can’t talk about – but it’s led to a fair amount of discussion about architecture, both inside the team and outside the team.

Which has got me thinking about reuse.

Reuse has been one of the Holy Grails of software development for a long time, along with… Well, work with me, I’m sure there are others. True AI!. That’s another.

Anyway, reuse has been discussed since time immemorial (October 13th, 1953), for some pretty sound reasons:

• Software is hard and expensive to develop


• We already break things apart into “components” to simplify development


• We’ve all written subroutines that are used in multiple places.

It seems that if we did a little more planning, paid a little more attention, were just a little smarter, we could build our components in a more general way, and others could benefit from them.

And yet, people have been trying to do this for a long time, and have mostly failed at it. There are successes – widely-used successes – but they’re fairly small in number. Surprisingly, people are still optimistic about going down the reuse path, and since they are likely to fail anyway, I therefore present some rules that can help them get there faster.

Eric’s N rules for failing at reuse

Authoring reusable components:

• It really helps to have delusions of grandeur and importance. You are going to be the ones who succeed at doing what others have failed at.
  


• Pick a wide/diverse scope. You’re not building a good UI framework for client applications, your framework is going to work for both client and web applications.
  


• Plenty of technical challenge. That’s what makes it fun and keeps you interested.
  


• No immediate clients. You are building a *Component*, and when you are done, clients can use it.

In my experience, that’s more than enough by itself, but it helps if you can throw in some obscure algorithms and quirky coding styles. I’m already assuming that you don’t have any real tests.

Consuming other people’s components:

• You absolutely *must* sign up to work with something as it is being developed. There is simply no better way to waste vast amounts of time. Unfinished implementations block you, regressions set you back, and even if you don’t get those, you at least get hours of refactoring to switch to the new version. It’s best if you do this on a “milestone” basis, roughly every 6 weeks or so. That’s short enough that you’re randomized often, but long enough that waiting for bug fixes is really painful.
  


• Commit to using the other component early and deeply. If somebody asks, “what will you do if <x> is too buggy, too late, or doesn’t do what you need?”, you can’t have an answer.
  


• Make sure that your use of the component is a variant of what the component is really being used for. In other words, the creator of the component is building the thing to do <x>, and you want to do <y>, which is kindof like <x>.
  


• A quick prototype should be enough to ensure that you can do it.
  


• If you can’t get the authoring group to commit to producing what you want, take a snapshot of their code and work on it yourself.
  


• Don’t plan any schedule time or impact to deal with issues that come up.
  


• If possible, buy the component you’re using. Because if you paid for it, the quality will be higher, and they’ll have to give you good support.

I hope these tips help you.

If you’re a bit leery of reuse, then good for you. I have only a few thoughts to offer:

If you’re thinking about doing something, it’s always a build vs buy decision. Even the best general-purpose framework out there is just that – a general-purpose framework. It’s not designed to do exactly what you want to do.

In the abstract, there are three phases of using a component in your code:

Phase 1 is great. The component is doing what you want, and it’s quick and easy to do it. Let’s say for sake of argument that this gets you to the 80% point in your project, and it gets you there quick.

Phase 2 is a harder. You’re starting to reach the limits of the component, and it’s tough to get it to do what you want. Tough enough that it’s taking more time, and you’re using up the time that you saved in phase 1. But you still feel like it was the right decision.

Phase 3 is much harder. It’s taken you as long to get here as a custom-written solution would have taken, and making further progress is considerably slower than if you had written everything. Worse, you can see the point where you’ll reach a wall where you can’t do anything more, and it’s close.

Different projects obviously reach different phases. Some never venture out of phase 1, and others are deep in phase 3. It’s hard to tell where you’ll end up, but if a given component is central to what you do, you are much more likely to end up in phase 3.  

The obvious problem is that prototyping is always done in phase 1, and the rapid progress you make there is oh-so-tempting. The whole application UI is laid out in a week of work using Avalon. I got this demo with moving pictures done in 3 days using XNA. We all want to believe that it’s really going to be that easy.

Stay strong against the lure of the siren song.