Pair meditation

Yesterday I stumbled across yet another instance of some guy propagating the idea that Pair Programming is the silver bullet for producing high quality code quickly. The fellow based it on the observation that "it worked while I was in college" and then extrapolated wildly, elevating it to Universal Truth.

Fact of the matter is that the people who were pushing pair programming screwed up. Their "tests" were pure pseudoscience of the kind Richard Feynman was trying to warn young people about when he pointed out that most of the time, scientists work hard not to fool themselves. It was shit science and unfortunately it got stuck in people's minds.

Which tells you something about what a bunch of sheep programmers can be.

Tests that were of far better scientific quality were performed by the Simula institute a few years later; showing what most intelligent programmers I know suspected all along: it depends.

Indeed, pair programming seems to work brilliantly -- for inexperienced programmers. I attended the talk where the paper was presented. I was one of perhaps 5 or 6 people in the audience. One or two years earlier, at the same conference, one of the main proponents of pair programming had unabashedly stood on stage and preached unadultered pseudoscience to a packed room, and the dumb sheep in the audience just bought it.

I can't remember if the study also looked at what activities are suitable for pair programming, but it has its uses. For me it works to have another pair of eyes when I am trying to hunt down a bug and I am stuck. Having someone stare at my screen while I program, or worse yet, having to stare at someone else write code, doesn't work for me. I knew that years ago. I do try to pay attention to what I do.

Anyway, my friend Jon had the best description ever of pair programming so far:
Pair programming makes about as much sense as pair meditation

Now, the next time you see someone trying to pass off pair programming as a silver bullet, please hit them over the head with a clue-by-four and tell them to apologize to Isaac Newton and Richard Feynman for taking a crap on their principles.

Show me the numbers, please

A few years ago someone decided that you need a driving license, rather than just a short course and a permit, to drive 50cc scooters and the like. Now these 50cc scooters and mopeds had a lot of limitations. Their maximum speed was capped at 45km/h, only one person can ride on them and they had rather anemic engines. It was also prohibited to drive them on highways.

I used to own a moped when I was 16. It was great for mobility since I grew up in rural Norway. Perhaps the rules were a bit different back then, but mine could do almost 80km/h and I think it was only supposed to do 50km/h or 60km/h (no, I didn't modify the engine). I dread to think what my teenage years would have been like if I didn't have some legal means of transportation back then. Being dependent on others for transportation would have been no fun. Of course, the fact that by the time I was 16, about half a dozen people I knew had either been killed or injured for life also made me value not having to bum rides off people just a couple of years older than me.

Interestingly enough, all of them in cars. As passengers.

So a few years ago, the powers that be decided that it would be a good idea to bring an end to easily accessible motorized personal transportation in Norway. It had to happen sooner or later. As a nation, we try to clamp down as much as possible on any form of personal transportation that doesn't involve strapping planks to your feet and suffering endlessly.

There has always been an option though: You could get a A1 license. A license that will let you drive a 125cc lightweight motorcycle with up to 15hp -- and you can take a passenger. But that meant you had to get a driver's license, and that was a tad expensive and a bit too much hassle. You really had to want to drive a 125cc motorcycle to shell out a load of cash just two years before you were going to shell out a lot of cash again for a B-license, which in Norway is the normal driving license for a car.

Percentage-wise, not a lot of people bothered with the A1 license, and those who did, had an above average interest in motorcycles.

Today it seems fairly pointless to get a license for a glacially slow scooter when you can get a license for a lightweight motorcycle instead. Apparently a lot of people go for this option now -- a bit more expensive; lots more flexibility. I would guess fewer 16-year olds drive a scooter, moped or motorcycle in total, but the ratio of scooters and mopeds to lightweight motorcycles seems to have shifted. I see more lightweight motorcycles out on the streets than before and I see a lot of pretty aggressive driving.

So the upshot of this seems to be that we have a sharp increase in young drivers on far more powerful vehicles, capable of much higher speeds and much higher levels of acceleration. Sure, they get to go through a longer course, but any instructor who is perfectly honest knows that you can't drive worth shit when you are done. It takes a lot more time to become comfortable on two wheels. Especially if you drive something with a lot more grunt than a 50cc scooter.

Call me a nut, but I'd like to see the numbers that say this is a good idea. I'd like to see the numbers that say significantly more kids on light motorcycles is such a great idea for reducing the number of traffic fatalities. Hey, I might be wrong, but on the face of it, it looks counterintuitive and every morning I see banzai moves in traffic by kids on 125cc bikes. What gives?

Actually, what I'd like to see is 50cc scooters and mopeds that can do about 70km/h comfortably. Doing 45km/h in traffic is too dangerous and disruptive to the general traffic pattern and I'd like to meet the moron who thought 45km/h was a good idea. Obviously not a driver.

I also think the license for 50cc scooters and mopeds should be free. Make it an elective in school and have the government pay for it. If they want to reduce the number of deaths on the road, the only thing they can do to help is to ensure that the quantity of practical training available to everyone is increased sharply.

That means one thing: the opportunity to get substantial quantities of practical driving training for free. Let kids spend a whole year training for free and let them get lots of driving done.

Driving is one of those things you only get good at by doing it.

The current rules accomplish only one thing: increase strain on the wallets of parents of teenagers and lining the pockets of the people who are only providing training that has symbolic value. This is not producing better drivers.


Measuring productivity

These days, measuring productivity in the number of lines of code produced seems to be generally viewed as being rather silly. Yet people still do it. People still use LOC as a metric for productivity in casual conversation. And there is a lot of ooh and aah when someone excretes a high line count per day.

If you are someone who is interested in software metrics, I have a challenge for you. Come up with a metric that meaningfully indicates the cost some unit of code incurs. This metric should reflect the fact that some programmers produce code that, while strictly speaking implementing the announced functionality, is so hideously clumsy, inelegant or stupid that other programmers, who have to use it, integrate with it or understand it, end up wasting time trying to do so.

This metric can then be used to indicate productivity more meaningfully: productivity is the sum of your contributions, plus those contributions your code made to other programmers productivity. The important aspect here being that the latter can be negative -- and far too often is.

Almost every day for as long as I have been a programmer, I've had to deal with code that has negative value: code that is so bad that it in the long run it would be better to replace it or avoid it. I've also worked on more than one project that has failed to meet its goals because it depended on defective and/or badly designed code.

If there was some measurable metric by which this code could easily be identified in an objective manner, programmers might get the feedback needed to understand when they are writing code that has negative value.


Indiana Jones

Went to see Indiana Jones yesterday. Not sure what I expected but I didn't expect the movie to be so mediocre. Don't get me wrong, it was entertaining and all the action ingredients you'd expect were there. But it just wasn't a movie I'd bother seeing again. A bit like the sequel to "National Treasure", which was also suffering from either a weak script or bad editing -- or both.

I think what I missed from the movie was an identifiable goal for the storyline. At any given time it should be possible to list the top 2-3 priorities for the hero -- apart from "staying alive", and I think the story, the hero's main mission, was too vague. Every now and then you'd catch a glimpse of it and think "Oh yeah, that's right, they were looking for a cave. Or something." There's a lot of running around and physical drama (as you'd expect) but no solid story to tie everything together. It's an action movie. The story needs clear and identifiable success criteria for the hero. This movie was just a bunch of action sequences and nice visuals, some attempts at political commentary and self-referential nostalgia (remember the scene where they pull Indy out of the trunk and you see his shadow when he puts on the hat? I cringed at the cheap "the hero returns" imagery).

My rating of the movie: "meh".


Coffee infrastructure updates

As I type these words my hands are still shaking from the massive amounts of caffeine I have consumed today.

Today I picked up my new coffee grinder at Dromedar. I think this purchase sets a new standard for customer satisfaction. It all started when I sent them an email and asked them for some advice on a coffee grinder I was considering. Roy called me back the day after and we chatted about coffee grinders for a while. It is always fun to talk to people who really care about what they do.

Roy told me that the grinder I was considering was indeed a great grinder, but he had just gotten word that the Mazzer Mini was available from their reseller of choice at a considerably reduced price -- so for a few bucks more, I could have the same grinder that they use in their coffee shop. So I figured why not, and ordered it.

The grinder arrived a couple of days later and he called me back. Now, not only do they take care of the order for you; when you buy a grinder from them they give you a brief introduction to calibrating and using it too! So after work I went over to one of their cafés, and Kjetil from Dromedar showed me the ropes. We took the grinder out of its box, assembled it and Kjetil explained how the thing works. Then we loaded the thing up with some coffee-beans and went on to find the right settings for perfect espresso.

We experimented a bit with the settings, and Kjetil pulled some shots to demonstrate the effects of having the grinder set too finely or too coarsely. He explained how to diagnose problems, how to do proper tamping, the importance of filling the filter correctly etc. When we were approaching the right settings he let me pull some shots and to my surprise they came out okay.

Then we packed up the grinder and I hurried home. Impatient to try it out.

I am now in coffee heaven. :-)

A big thanks to Kjetil and Roy from Dromedar for a brilliant customer experience. It isn't often you find people who are as helpful and as passionate about what they do as these guys!

TODO list for Steve Jobs

hi Steve,

...me again. As you know by now, I am a big fan of MaxOS X -- and that's something since I am one of those guys who has been using UNIX on laptops since before Linux reached version 1.0.

BUT, there are some things still left to do in MacOS X that you appear to have forgotten about, so here is a quick recap of what you need to do before the next update of Leopard.
  1. Fix the annoying login dialog problem when you open a mac after it has been suspended. It pops up and then waits for a short while and then goes away again, and doesn't come back, if you don't pay attention to it. In general, going to/from suspended state is a hassle. At the very least figure out some way of telling the user which state the machine thinks it is in and what state it is trying to change to.
  2. Fix front row. I have yet to use Front Row without it crashing on me and unless I am at home, so I can log into my laptop via SSH from a different machine, it just hogs the screen and keyboard and I have to restart the machine. Front Row is not usable. Ditch it or fix it, but choose one, please.
  3. iTunes is a big part of the MacOS experience, we all agree on that, right? OK, now user interfaces that are unresponsive are bad. You should have some books on usability floating around the office: read them. Then have your programmers read up on concurrent programming. iTunes currently can't walk and chew gum at the same time. In fact, it can't breathe and chew gum at the same time.
  4. Terminal should have default behavior that is closer to how terminals behave under X11 with regard to termination. When the shell terminates, please clean up the window -- that's how the gods of UNIX intended it. Pressing Cmd-W is superflous and it is really annoying that Cmd-W is dependent on the config and that the default does the wrong thing. Also, in Leopard, for some reason, the keymapping went all wonky so I can't type "[]{}|\" etc. I haven't found any solution for that last problem so I now use a third party terminal. I really think it would be neat to have a non-sucky terminal shipped with Leopard.
Thanks for listening Steve. I am sure you will print this note and stick it to your fridge and look at it every morning until the next Leopard update.