Collaborative development, pair programming, etc.

January 31, 2006 at 3:28 am

There have been some interesting discussion on our internal “agile” alias around pair programming, with some advocates and some skeptics.

I wrote something in response to one of the skeptical posters, who (to paraphrase badly and perhaps miss his point) said that he was an introvert and preferred to work alone. Not that I’m advocating forcing something like pair programming on anybody.

Here’s what I wrote, slightly edited to protect the innocent.

*****

The introvert/extrovert concern is an interesting one. I like to be left alone at times, and I’m also a big fan of flow state.
 
But I’m also pushing for us to *experiment with* pair programming in our next cycle. Why?
 
Well, I’ve been on a lot of projects in my career, and I see the same bad things happening over and over again. Code reviews that don’t happen. Important components that one or fewer people on the team understand. Overly grandiose architectures. Re-inventing the wheel. Solutions looking for problems. Bad bugs that are really expensive.
 
Who is at fault? Well, we are.
 
For example:
 
You’ve just finished adding a new feature, and to do so you had to do a bit of re-architecting to fit it in. Do you ask one of your co-workers to review what you’ve done before you check it in?
 
Reasons you get the review
  1. It’s the right thing to do
Reasons you skip the review
  1. You’re an introvert. Given the choice between personal interaction and working on something new, you usually choose something new.
  2. Your co-worker is also an introvert.
  3. Nobody really understands your code because you’re the only one who works on it, so the review may not give useful feedback
  4. You have to get up, leave your office, find the person, and bring them back. Lots of time, and they may not be there.
  5. You get evaluated on the features you produce and don’t feel review pain because of the bugs in your code.
  6. It’s early/late, and you’re by yourself
  7. You don’t want people to say bad things about your code.
There are a lot of factors pushing you to do the wrong thing, so it’s not surprising that the right thing rarely happens.
 
So what about TDD? Well, I think TDD is a great way to get code that has fewer bugs in it, and I don’t underestimate the value in that. But TDD doesn’t address code maintainability issues – you can still write overly grandiose and poorly factored code using TDD. You can still write code that is inconsistent with code elsewhere in the project, or using the wrong library. You can still spend hours trying to figure out something where the group knowledge could have solved it in 5 minutes. And – as I am chagrined to admit – I can still write code that should be under TDD but isn’t because it wasn’t convenient.
 
I don’t think that collaborative development – by which I mean anything from co-location in a big room to pairing – is a silver bullet that is going to solve all these. But I think that it can make a pretty big dent. And as a company, I think we have to figure out a way to stop producing big legacy codebases that nobody wants to work on.

2006 goals, and bicycle coaches

December 29, 2005 at 5:57 pm

I was reading Fatty, and he talked about his goals for 2006. So, I thought that I’d talk about mine, and perhaps give him a bit of advice…

I’ve decided on my bicycle goals this year. My big rides are going to be:

STP One-day (July 15th)

I’ve never done STP. I’ve thought about doing the two-day variant, but I didn’t really want to go on a ride with 8000 of my closest friends. Last year I was probably in shape to do the one-day version, but I didn’t know I’d be there in March when I needed to register.

RAMROD (July 27th)

RAMROD (Ride around mount rainier in one day) is a 143 mile ride all the way around Mt. Rainier. It features around 10,000′ feet of climbing. This will be a  long and hard ride.

I think that I can get into decent shape on my own, but I’ve been thinking of spending some money on a coach. Since I don’t have any racing aspirations, it seems strange to think about a coach, but I’ve taken ski lessons for the last 5 years or so, and it’s had a tremendous impact on both my ability and my enjoyment. I spend enough time on my bike training (well, much of it is just *riding*…), and I’m pretty sure I could be more efficient in using that time.

Carmichael provides an entry-level service for $40 a month that gives you a program to follow that I’m thinking of using.

Anybody tried Carmichael, or any other coaches?

Oh, and Elden, I noticed that Carmichael also provides nutritional consultation. If you’re planning on dropping that much weight, it might be worth considering…

The last few days, I spent eating, sleeping, and reading, so today I got back on the bike and did 25 miles with just under 2000 feet of climbing.

Flow vs. Collaboration

December 16, 2005 at 1:31 pm

I’ve been talking about some agile techniques with one of my co-workers, and one of his concerns about pair programming or not being in separate offices is that he won’t be able to get into a state of flow in that kind of environment.


My limited experience with working on projects in group settings leads me to believe that the benefit you get from informal collaboration is far more important, but I’d like some more data.


What do you think? Is the lack of time for flow a real issue, and if it is, how do you deal with it? Or do you find that the collaboration is more important.

Overtraining

December 8, 2005 at 6:45 pm

Fatty is talking about overtraining as a possible excuse for not riding, and mentions Friel’s statement on overtraining ()

Less than one-tenth of one percent of the general population is capable of attaining such a feat.

That’s a pretty powerful statement, and Fatty uses it to assert that only the upper level of pro athetes can overtrain (it’s not clear to me if his statement is another Friel quote, or a paraphrase, hyperbole, or the product of too much of “the best cake in the world“)

To me, what it comes down to is this question:

Is my overall fitness level going to be better if I:

a) train today?
b) rest today?

If the answer is “b” and you train today *anyway*, you are overtraining. Of course, there are some caveats – your “training” today might be more “active rest” than training.

So, how many cyclists overtrain? Well, my experience is that many people – especially those who like to push “until I start getting tunnel vision” – tend to have trouble controlling their intensity. Friel says:

Generally, a week should have at least as many recovery workouts as hard workouts, if not more. Every third or fourth week there needs to be a period of greatly reduced training with an emphasis on rejuvenation.

Carmichael says something similar.

So, anyway, my point – and there is a point this time – is that many – if not most – serious recreational athletes are in danger of overtraining now and then. I have a friend (no, really, a friend…) who would ride his bike “all out” for 75 minutes every night for a period of months. I don’t see how he could be anything but overtrained.

Over the weekend…

November 1, 2005 at 10:16 pm

There I was, minding my own business, without a care in the world. And then it happened…

Well, to be truthful, it was at least partly my fault. Perhap I should back up a bit.

I was at home, at about 5:15, glueing gravel to my face. It was going pretty well, and as I was adding the gel blood, I knocked my helmet off, and the moss fell out of my helmet. What a mess.

Perhaps some details are in order:

  1. Embedded in my chest is a 30 tooth 105-series shimano chainring. Well, part of a chainring – the rest is coming out of my helmet
  2. There’s a spoke coming out next to the wound near my right eye. Another coming out of my bike shorts.
  3. Wounds on my face, right arm, left wrist, and right knee.
  4. Chain (shimano ultegra 10 speed)
  5. Remnants of an inner tube coming out my left leg.
  6. Moss in the helmet

Important safety tip: If you decide to do something like this, I suggest taping the aforementioned cycling parts to your shirt, if you’re interested in the easy way out. If, however, you wish some assistance in projecting your injured tape, adhesive tape works well.

Flow, and Cycling

October 31, 2005 at 10:39 pm

Tonight I read a post by Eldon, where (among other things) he says that he has learned how to lose himself in his ride. I’ve experienced that a number of times – I’m just riding, still paying attention to what’s going on, but not thinking about anything.

I’ve been thinking about how that relates to the flow state when programming. In my experience, it’s a lot easier to get into the flow state when programming than it is to get into the analogous state when riding. It may have to do with the degree to which you can shut out external input. In programming, it’s pretty easy – put on some appropriate music, and lose myself in the task. On the bike, it’s often not possible, since losing oneself can have some pretty bad consequences.

Thoughts? Are the two states analogous, or are they different things entirely?

Review: Working Effectively with Legacy Code

September 30, 2005 at 6:40 pm


I’ve read a number of books about Test-Driven Development. There are a number of new ones, but most of them start with a clean slate where you’re writing code from scratch.


Working Effectively with Legacy Code is different. It starts with the assumption that you already have a codebase that doesn’t have tests and need to figure out how to start adding tests as you work on the existing codebase.


The book is organized into two sections. “The Mechanics of Change” are an introduction to TDD, tools, why you would want to do it, etc. The real meat of the book is the second section, “Changing Software”. Each chapter in this section addresses a different question, such as:



  • I can’t get this class into a test harness

  • This class is too big and I don’t want it to get any bigger

  • We feel overwhelmed. It isn’t going to get any better

And each chapter has a detailed discussion of the problem, the strategy or strategies you might use, and the tradeoffs involved. That last point is pretty important – the Agile community has more than its share of zealots, so there’s a lot of dogmatic advice out there. This book is the opposite – the author has clearly spent a ton of time applying his techniques to real codebases, and there are lots of interesting discussions out there. Even if you aren’t sold on the whole Test-Driven approach, there’s a lot of content that will apply to general refactoring.


This is one of the best books I’ve read in the last few years. Highly recommended.

Heart Rates and Climbing

September 27, 2005 at 12:26 pm

A couple of blog comments sparked the following question from Chris:

As I rode the Zoo my heart-rate hovered between 180 and 184. 184 is the absolute highest I have ever seen for me on a bike. My resting heart rate is roughly 56. Out of curiosity…. can anyone explain what it means that I have a higher resting heart rate and apparently a higher max heartrate than Eric.

That’s simple. I have achieved the morally superior lower heartrate, and it doesn’t matter how much faster you are, I’m going to be the better cyclist.

Don’t buy that? Well, it’s a simply matter of physiology. We aren’t surprised that certain people have larger hands, or heads, or ears than others, so it’s probably not a surprise that people have different sized hearts. My heart is simply bigger than yours. In fact, the stroke volume (the amount of blood pumped per beat) can vary as much as 4x between people. That’s an impressive difference, though it would admittedly be more impressive if I hadn’t pulled that “4x” number out of thin air.

I used to work out with a woman whose heart rate at comparable level of exertion would be be something 1.6 times my heart rate. I’d be hanging out at around 120, she’d be up above 190. No problem for her, but a great indication that things like “heart rate ranges” and “220 minus your age” don’t work well with the whole population, and may be pretty bad for specific individuals.

As you may already know, increase in stroke volume is one of the primary adaptations from training.

The Physics of Bicycle Climbing (oh, and a few words about a stupid bicycle climb)

September 25, 2005 at 12:46 am

Last night, when I got home, my wife asked me if I’d read Eldon’s blog. A quick look showed that he was trash talking about today’s ride. Me, I don’t need to trash talk or work to psych anybody out, because I’m confident in my climbing skills. So confident, in fact, that I thought I was a virtual lock to make it to the top of the hill, and even pick up some time over my previous ascent.

Despite the fact that I run BicycleClimbs.com, and unlike Eldon, I’m not a particularly gifted climber. I’m learning how to suffer (more on that later), but my physique is not suited to be first up the hill.

The sport of bicycling has lot of variables. Wind and aerodynamics play a huge part, as does drafting. But when you get to the steep hills – unless you’re talented to ride up them at meaningful speeds – it’s mostly about power/weight ratio. I was thinking about this a few days ago, and dusted off some disused physics expertise.

First, we need to figure out my potential energy at the top of the hill. For that, we’ll use the following formula:

PE (Joules) = mgh

My bike and I weigh pretty close to 200 pounds (a few pounds less, but that doesn’t matter) = 200 / 2.204 kg = 91 kg. That’s the m.
Zoo hill is 1200 feet = 1200 * 12 inches = 1200 * 12 / 39.3 meters = 366 meters. That’s the h.
Finally, g stands for gravity, and for the earth, it’s 9.81 m/sec^2

So, that gives me:

PE = 91 * 9.81 * 366 = 330000 Joules (if I mess up on the significant digits, my wife will kill me.)

All that is left is to convert that to Watts. Conveniently, 1 Watt = 1 Joule / sec. I climb the zoo in 25:30, so

Climbing Power = 330000 / 1530 = 220 Watts

There’s some additional sources of resistance, but they probably aren’t that big for the Zoo, especially at the speeds I ride.

Eldon wrote that he did the Zoo last week in about 21 minutes (lets say 21:30). That’s a ratio of 0.84 to my time. To match that, I either need to up my power output to 220 / 0.84 = 262 watts, or I need to reduce my weight by the same factor to 180 * 0.84 = 151.2. I did weigh that much in high school, but I had less upper body muscle than I do now (hard to believe, I know).

So, class, what did I prove? Well, I proved that there was no way I was going to beat Eldon. But maybe there was another way. For the climb, I wrote up a few guidelines and printed them out, along with a map. Here’s what they said:

  • It’s tough to get lost. Just keep going up. When you get to the stop sign, turn left. When there’s a green gate on you’re right, you’re at the top, and it’s all downhill from there.
  • On the descent, turn left at the stop sign.
  • This is an unsupported ride, so if you stop, you will fall over.
  • Limit your speed on the first pitch. In fact, you should probably stay behind me the whole ride, just to be safe.
  • Those who reach the top may choose to coast back down to ride up with those who haven’t made it up yet. Those who haven’t made it up yet may choose to whack those who have made it with their pumps.
  • The organizers request that any riders who pass out attempt to do so that their bodies will roll onto the shoulder.
  • Those with something to prove should ride the inside of the hairpin. Those with a lick of sense should ride a more rational line.

I then handed Eldon a sheet and asked him to read them out loud, with the excuse that I didn’t want him to be the only guy who got to be funny.

What he didn’t know was that his sheet was special. All the other ones had an additional guideline which said:

  • (This guideline isn’t on Eldon’s sheet, so don’t ruin it). $20 to the top finishing rider who beats Eldon to the top. I’m not kidding on this one – I have the cash with me.

Yes, if I can’t beat Eldon myself, perhaps I can pay somebody to do it. Eldon claims that that is evil. Hmm. What did I read yesterday? Oh, yeah, “I will pay other people to interfere with my boss’s boss“. Yeah.

So, anyway, we did the ride, and I displayed my mad climbing skillz. I bumped my average heart rate up about 5 points, and got up in a time virtually indistinguishable from last time. And I wasn’t last to the top, though I should note that of the two guys arriving after me, one started 10 minutes behind me, and the second was about 5″ taller than I am.

But I am learning to suffer better.

 

The Double-E half-hour of Pain (You do Zoo, We do Too)

September 20, 2005 at 12:32 pm

One of my readers suggested a group ride of the Zoo, so I’m teaming up with the Phat Psyklist to put on the:

The Double-E half-hour of Pain (You do Zoo, We do Too)

September 24th, 2:30 PM at the base of the hill. Eldon said something about cake at the summit. If you want to participate, please send email or leave a comment so we have some idea how many people are showing up.

This is not a climb to be approached lightly. Proper preparation includes a well-maintained bike, good legs, a sufficient arsenal of excuses, and willingness to explore the outer limits of performance and whining.

Notes for first time zoo climbers:

  1. Start slow. Really slow. Lowest gear slow. Almost falling down slow.
  2. You’ll need to maintain your pace for somewhere in the neighborhood of half an hour.
  3. After about 0.8 miles, there is a hairpin turn to the right. Do not ride on the inside of the corner. The easiest way up is the outside of the turn, if traffic conditions permit (there is usually little traffic on the zoo)
  4. The first mile or so to the straight section is the worst. The straight section to the stop sign is harder. And the section after you turn left is harder still.
  5. The top is at the gate, and the road turns to gravel soon after that.
  6. Don’t descend the same direction – head west on 60th (ie left at the stop sign coming down from the summit)
  7. Ever climb Inglewood? The zoo is like riding Inglewood. In a higher gear. Four times in a row.