Eric’s Code Shack

I’ve been writing a small utility to help us do some configuration setup for testing. It needs to walk a directory structure, find all instances of a specific xml file, and then make some modifications to the file.

I TDD’d the class that does the XML file stuff, and I’m confident that it’s working well. I’m now going to do the class to walk of the directory structure and find the files.

And there is my dilemna. I don’t know if I’m going to do TDD on that.

I know exactly how to write it, I’ve written it before, and my experience is that that is code that never changes nor breaks. And, figuring out how to write tests for it is going to be somewhat complex because I’ll have to isolate out the live file system parts.

So, I’ve already decided what I’m going to do, but I’m curious what you think. Does YAGNI apply to test code, or is that the first step to the dark side?

Today I did my first hard ride of the year, the 11-hill version 58-mile “metric century” 7 hills ride. Last year I did CTS training, and while it did great for my aerobic endurance, I didn’t think it had enough strength work or interval work. This year I’ve been spending more time pushing bigger gears, and have been doing the majority of my rides on my middle chainring (rather than the tiny one). I’ve also done some core work, and am starting to do some specific climbing workouts.

Looking back at my HR data from last year, I averaged 13.8 MPH for 46 miles with 2900 feet of elevation gain (which included a quick ride to the start and a pretty slow ride home afterwards). This year, I averaged 15.3 MPH for 59 miles with 4125 feel of elevation gain.

That’s a pretty significant improvement, though some of it also came from climbing at a cadence of around 85 RPM vs the 100 RPM that I was targetting last year. The lower cadence seems to allow me to work out at a higher effort with less cardio load, which is good as long as your legs hold out, at which time you have to switch to spinning. Or you need to do it if your knees fall off.

The ride itself was very nice. A bit cold (49) in the morning, but overcast with a bit of sun and not too warm, with no wind. The ride was nicely run as usual, and it seems that it’s growing each year. Recommended if you like hills.

This year, I got into RAMROD (though it should more correctly be named “Ride on the Eastside of Mount Rainier in One Day because the roads are washed out” – I guess ROTEMROD isn’t terribly catchy…), which features (among other things) a climb up Sunrise. Sunrise being a small visitor center on the east flank of Mount Rainier, a great place to visit, so much nicer (and sometimes less crowded) than Paradise on the south side. If you look at the page on the climb, you’ll see that it’s about 3000 feet of climbing, which is something I haven’t done yet.

So, given that I’m off this week between jobs, I spent the night at my ski place in Skykomish, and rode up Stevens Pass, which is very similar to Sunrise. I started at the Skykomish city park on the north side of the river, headed across the tracks to ride old cascade road to where it met highway 2, and then up and up to the summit. The weather was bright sunny, and about 45 degree at the start.

The first 6 miles is a warmup. There are a few bridges where you need to look for a break in traffic, and a bit where there’s not a lot of shoulder. There are also some steep parts and some flat parts (and one pseudo-flat part…). Given how often I’ve driven this route (easily in the hundreds of times), I was struck by how different it is at 11 MPH. You’re near the river for the bulk of the time, and the sound of rushing water is never far away. It’s really pretty and the light traffic didn’t really detract from the experience.

Things start getting steep at Deception falls (a nice stop when you’re in the area), and once you get to Glacier, you leave the river and the railroad behind and just climb. The shoulders from there on all the way up are great, and the road is two lanes the whole way, so there are few traffic worries (though the large trucks laboring up the hill at 25 MPH do get your attention).

I settled in and did the remainder of the climb at around 7.5 MPH, with my HR somewhere in the 130s, which was fairly comfortable from a HR perspective but not really from a leg perspective. Though the temp was in the mid 40s, I had to take of my jacket off to stay cool enough, even in the shade. The last mile or so was enhanced with a nice 10 MPH headwind coming from the east.

At the top, I sat down on the 6-pack chair next to the granite peaks lodge (that Stevens bought someplace surplus, since they don’t have any 6-person lifts), and rested while looking around. If you were willing to do some hiking, you could still ski skyline top to bottom with only a couple of bare spots.

Stats:

16.1 miles
1:43:51.7
Average speed: 9.3 MPH
Average HR: 137 BPM
Elevation Gain: 3175 feet

Steep part:

9.5 miles
1:13:45
Average speed: 7.7 MPH
Average HR: 142 BPM
Elevation Gain: 2680 feet

After 20 minutes of rest, I put on my jacket and headed down. I did the steep part in 19 minutes, at an average speed of 31 MPH (would have been faster, but I had to slow down for hairpin because the pavement is really torn up). The total descent took 36 minutes, averaging 26 MPH.

Overall it was a nice ride. I’d definitely recommend a weekday rather than a weekend.

I was reading a “Joel” post (I like Joel’s writing, but I wish that he allowed comments) entitled “The Econ 101 Management Method“, which I find myself mostly in agreement.

I’d like to expand a bit in the area of metrics – specifically what I call “surrogate metrics”.

Most software development teams are associated with what business guys call a “P&L center”, which in simple terms means that it’s part of the business that will either make or lose money. The measure of whether the group is making or losing money is an example of a metric, and it’s a good metric, in the sense that it measures exactly what it says it’s going to measure.

How important that particularly metric is to a company and what other metrics are also important is a different subject. As is the siren song of metrics in general.

The subject of this post is metrics don’t measure the thing that you want to measure, but are *believed to* correlate with the thing that you want to measure.

Say, for example, that you’re a software company, and you’ve heard through the grapevine that customers are unhappy with the service that they are getting through your support forums. A little research shows that some people aren’t getting prompt answers.

So, you spend some time writing a reporting layer on top of the forum software that tracks the time between when a post first shows up and it has a response from somebody in your company. You run it on some historical data, and see that the response time averages out at 36 hours, which makes you unhappy. You work with your group, tell them that they need to do better, and over the next month, the average response time goes down to 12 hours, and you’re happy that you’ve solved the problem.

Did you do a good job? Is the problem fixed? Discuss…

The answer to my questions is a rousing “who knows?” It’s possible that the problem is fixed, and it’s also possible that it’s still as bad as before. That’s because “response time” is a surrogate measure of the thing that you really care about, customer satisfaction.  You chose it because it was a *easily measurable*.

Which I guess does lead me towards discussing the siren song of metrics in general. There’s a real bias in some business cultures towards measuring a lot of metrics. As Joel points out, this leads to people gaming the system, which is an obvious issue. But even if people don’t game the system, surrogate metrics can, at best, suggest when something is bad, but they can never tell you when something is good enough.

Some people would argue that you should still collect the metrics you can, but I think you just shouldn’t bother with surrogate measures. Measure the things that you truly care about, and don’t mess up your culture and reward system by measuring the surrogates. And if you can’t measure the thing you really care about objectively, if it’s too hard or too expensive, you’ll just have to deal with the the uncertainty.

In my example, if you care about customer satisfaction in your support forums, then you need to ask customers whether their support experience was acceptable. There are lots of ways of doing this, and you can often use the same process to allow customers who had a bad experience to escalate it.

So, what is your favorite real measure and surrogate measure that you’ve seen? 

We’re at the tail end of the ski season here. I skied yesterday – in conditions that were less than exciting – and next weekend is probably the last time of the year, assuming the weather is worth it.

Over the past 7 years or so, my wife and I have taken a set of ski lessons (all at the excellent Olympic Ski School, teaching at Stevens Pass). We started because our daughter was going to be in real lessons, and we needed a reason (explanation) for why we weren’t going to watch her during lessons. (for the young parents who haven’t figured this out yet, having mom/dad hang around is a pretty good way to compromise your child’s improvement).

Those lessons have taken me from a pretty good intermediate skier, skiing all the blues and groomed blacks well and surviving ungroomed blacks to skiing pretty much everything in good snow conditions (though I’m not great in the bumps). Which puts me somewhere in the advanced/expert region.

Normally, when a new season rolls around, I forget the things I worked so hard to learn the last year and spend a few weeks skiing below where I want to ski. Which is why they are “Eric’s ski tips” – they’re for me, so I can read them next October. But I’ll try to phrase them generally…

Stand tall. While it’s okay to be compressed a bit, you need to compress at the knees, not bend at the waist.

Hands in front. This is about feeling the front of your boot, and not getting your shoulders rotated.

Block, then poll plant. This is probably my biggest insight of the year. I tend to be a fast skier (I topped out at 45MPH on a recent day according to my GPS), which is a lot of fun on groomed stuff, but not what you want on fresh or chopped up stuff. And I’ve often had trouble controlling my speed in those situations. This year, we were doing some pole plant exercises, and they weren’t working for me at all. My instructor had me borrow his (shorter) poles, and what do you know, my poles (which were sized using the “old school” approach of a 90 degree angle at the elbow) are too long for the kind of skiing I do. I went two sizes smaller (a full 10cm), and saw a major improvement. They don’t get in my way and they make it easier for me to reach downhill. So, now that I have the new poles, I can adjust my timing to block (a bit like what you do with a hocket stop) at the end of the turn, pole plant while in the block, and then release in the new turn.

Feet apart. This is mostly about getting angulation – if your feet are next to each other, it’s hard to get any curve (aka angulation) into your lower body – all you can do is bank. That’s fun on groomers, but will prevent you from doing short turns, and if your ski loses an edge, you fall down.

Look downhill. I usually don’t have trouble with this.

Balanced weight. On the groomed, when making big turns, you end up with the vast majority of your weight on the downhill ski. In shorter turns and especially in ungroomed snow, you need to have a balanced weight between the two – somewhere in the 60-40 to 70-30 range. This does a few things. First, it keeps your downhill ski closer to the surface of the snow (you’re using more surface area). That puts you in the lighter snow, and it also means that the weight transfer from turn to turn is less, so you can do it more easily and quickly.

Inside knee. Another big insight for me this year. Getting the proper angulation through the turn is controlled by what you do with your inside knee rather than your outside knee. If you get it to the inside, your outside leg has to follow.

Here hoping these help out next season…

Oh, one bonus tip.

My long-suffering Volkl vertigos had reached the point where they couldn’t be tuned, so I ponied up for new skis, and boots. The Soloman X-10s are wonderful – more floaty than the volkls, but still stable at speed. The soloman boots are also very nice – they have a softer flex than my old nordicas and also have more space in the angle box to allow some angulation in the angles. Finish that up with some nice custom footbeds, and that’s a setup that are very comfy and don’t have to be tight to perform well. If you’re an intermediate skier, the benefit to be had from good boots, custom footbeds, and higher-end skis (in that order) is well worth the investment.

Oh, and woo-hoo! No cracked ribs this year!

Software is always built on other software – your dependencies – and the dependencies that you choose have a considerable influence on your success. Choose the existing technology that you know, and you have good predictability, but you might not produce a great product, or it might take too long to finish. Choose a hot new technology, and it’s harder to predict what will happen. Maybe the benefits will be great and you’ll finish faster (ASP.NET vs old ASP…). Maybe things won’t be as good as promised (insert the name of a technology that you were “disappointed with” in the past).

Or maybe it’s not finished when you need it. Welcome to the wonderful world of co-development, where you are depending on features that aren’t implemented yet. How do you reduce the risk of features/APIs not showing up, or being substantially different than you expected?

Well, the first (and best) way to reduce this risk is simply not to do it. If you only depend on features and APIs that are currently available, you know they are there.

If you can’t wait a full release cycling, then perhaps you can take some sort of incremental approach, where you plan to use feature <X> but don’t *commit* to using it until its actually there. My preference would be an agile approach (such as Scrum), so that when feature <X> shows up, it’s actually finished and working.

That’s really just the same thing I said first – don’t take on the dependency until something is done.

But what do you do if you really need that feature – if your plans would be derailed unless the other team finishes the feature? I have four things in mind that can help:

Accept the Risk

First, you have to accept that you are taking on risk. Software scheduling beyond a period of a month or two is not only an unsolved problem, I believe it isn’t a tractable problem. Decades of project slippage have demonstrated that, and we should just embrace the uncertainty involved rather than trying to “do better”.

Note that while there are teams out there that can give good estimates for tasks in the next month (and perhaps up to two months), you can’t assume that you are dealing with such a team. There are many teams who are essentially unpredictable even in short timeframes.

Understand the Risk

Second, you need to understand the risk. This will require you to work with the team that’s building whatever you are needing. You need to understand where your feature ranks in the things that they are doing. It might be a feature that they absolutely have to have to ship, or it might be a “nice to have” feature. You need to understand this. It’s closely related to how close your requested feature is to their main charter. You do not want to be the outlier group amongst all their clients, the customer they don’t want to have.

You also need to understand when they’re building the feature. If it’s very early in the cycle, then it’s likely to get done. If it’s late in the cycle, it’s less likely to get done.

If they don’t think of features in this way and/or are working on features in parallel, it’s more risky.

It would also help to understand what development methodology they use, and their history of being done when they guess they will be done.

Plan for Mitigation

What are you going to do if things don’t work out, if the feature is late or is cut? Even in the best organizations, people get married, are out for months on medical leave, have accidents, or leave to form their own companies.

What is your group going to do when this happens?

Track the Risk

In an ideal world, the group you depend on would give you regular updates about the feature you’re waiting for. And some groups do do this, but it’s your risk, and you’re going to need to stay on top of it. The details of that depend on the groups involved.

Accept the Outcome

If things work, great. But if the feature doesn’t show up, remember that you were the one who accepted the risk in the first place.  

We’ve been spending some time trying to figure out what our team can get accomplished in the next 6 months or so. We have a feature list that we’re considering, and we need to apply some numbers to it.

So, I decided to try using Planning Poker. I made up some index cards with values in dev-weeks, in the values 1/4, 1/2, 1, 2, and 4.

It has taken a fair amount of time to get through this process, but the numbers we got are a lot better than we would get with other methods, and more importantly, the dev team has a much better idea about what and how they’ll be building whatever we are building (I apologize for being evasive, but it’s a bit of an organizational disease right now).

Note that I’m not recommending all-up estimating. In general, I don’t think you should be costing more than a month or so worth of work at a time, as the quality of the estimates won’t be great. In this case, we needed a go/no-go number, and the estimates that we got were good enough.

Last fall, one of my friends accepted a job offer back east and needed to put his possessions on a diet. He called me up, and asked me if I wanted to take his Meteor.

Meteor, of course, being a pinball machine manufactured by Stern way back in 1979.

I drove to his house, picked up the machine (which had mysteriously gone from working to not working, apparently in the time it took me to drive across town), secured it in the back of the truck, and then took it up to the cabin, where I introduced it to Bad Cats.

And then it sunk in. When I only had two machines – one per house – I could deny it, but adding the third made it obvious.

I was a collector. Especially since the new machine didn’t work.

A bit of debugging found the first fault – there was a break in where the line cord was attached (a substandard solder joint). A quick wire nut fix (no soldering iron with me), and the machine woke up. More or less – there were a few playing issues, but it mostly just needed some light bulbs. A whole-lotta light bulbs (note to readers – foreshadowing!!!)

So, I headed on over to Pinball Repair Section of Marvin’s Marvelous Mechanical Museum for a repair guide, one of the sources of specialized information that makes the internet great.

Which leads to a brief aside. The Meteor is made by Stern, but the repair guide you need is for Bally machines.

When Stern started building machines, they needed a control system to use. They could have developed one from scratch, but that takes a lot of time and money. You could license it from another manufacturer, if they would do that, but they won’t because they don’t want the competition. So, Stern just stole the design, Bally sued, won, and got awarded… a license fee per machine. The same thing happened a few years later after Data East stole the design of the Williams control system.

I upgraded the woefully underdesigned power supply (which was apparently designed by the guys who took electronics with me in high school back in 1976), replaced all the bulbs (about 60 of them), turned on the machine and… None of the bulbs worked.

So, I re-replaced the bulbs, and then the fuse that supplies the power to the solenoids (bumpers, slingshots, drop target reset) started blowing. And the bulbs still didn’t work.

I checked a bunch of things, but couldn’t figure out what was going on.

Then I got lucky, like the program that finally crashes where the bug reports says it does. One of the power resistors on the power supply started smoking.

Generally, that sort of behavior isn’t the kind of thing you’d prefer from an electrical device, since you risk losing the Magic Smoke. But in this case it was great. I grabbed my voltmeter, put it on the resistor, and found 47 volts. Which was great, because it told me what was happening.

There is a 47 volt supply that drives the solenoids, but I was reading that voltage on the 6 volt supply to the lights. That was enough to blow the fuse, and it was also enough to make the bulbs *really bright* for a very short period of time.

It only took about 5 minutes to find a wiring harness section that was really tight, and the voltage came back to normal. Now I just need to replace all 60 bulbs again…

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…