Bald eagle observation

Posted in Random thoughts at 1:21 pm by ducky

As I was walking across campus today, I saw a bald eagle soar past — closely followed by five or six seagulls that harassed the eagle a bit.

After I got home, I saw two bald eagles land on a tree outside my window and sit in the top branches.  Again, I saw some smaller birds appear and harass the eagles.

I presume that the smaller birds hassle the eagles because they don’t want the eagles to prey on their chicks.  Maybe also the eagles prey on seagulls and smaller birds, but can only succeed if they have the element of surprise.  Maybe eagles have to grab the other birds from behind, snapping the smaller birds’ neck.  By harassing the eagles when the eagles are not at an advantage, maybe the smaller birds can convince the eagles to move on to the next forest over.

I don’t think there are analogous situations in the terrestrial world.  I’m trying to imagine a gang of rabbit thugs harassing a mountain lion, and the image — while amusing — just is not working for me.


Data mining for terrorists

Posted in Random thoughts, Technology trends at 10:11 am by ducky

Interesting article on how datamining for terrorists doesn’t work.

From the article: “Finding terrorism plots is not a problem that lends itself to data mining. It’s a needle-in-a-haystack problem, and throwing more hay on the pile doesn’t make that problem any easier.”


Google for Enterprises

Posted in Technology trends at 11:34 pm by ducky

I blogged before that I thought Microsoft was vulnerable, that Google should offer their email and calendar to businesses. Well, it’s happening now. It’s not clear if the data is on Google’s servers or behind the corporate firewall, but I’m guessing (from the lack of any saying otherwise) that it is on Google’s servers. Apparently Outlook causes enough pain that some companies are willing to let their data out of their control.

Upgrading from Firefox 1.5.x to Firefox 2.0.x on Ubuntu

Posted in Consumer advice, University life at 1:10 pm by ducky

I got a warning from the IT group that there was a vulnerability in Firefox 1.5.x, and that I should upgrade to 2.0.x. Fine.

I went to download via Synaptic (apt-get with a GUI). It didn’t have Firefox 2.0.x.

I downloaded the tarball from http://getfirefox.com and unzipped it. No obvious installation script. There was a readme.txt, which said:

For information about installing, running and configuring Firefox including a list of known issues and troubleshooting information, refer to: http://getfirefox.com/releases/

That URL redirected to the same page that http://getfirefox.com redirected me to. There was a link for Releases on that page. Unfortunately, all it said about installation was this:

Please note that installing Firefox 2 will overwrite your existing installation of Firefox. You won’t lose any of your bookmarks or browsing history, but some of your extensions and other add-ons might not work until updates for them are made available.

Swell. So I asked the Web, and found pages like this, which were slightly more helpful, but which seemed geared to installing and not upgrading.

It turns out that Firefox is in a self-contained directory. All I needed to do was to figure out where the old directory was and replace it.

% which firefox
% ls -l /usr/bin/firefox
lrwxrwxrwx 1 root 22 2006-09-25 20:19 /usr/bin/firefox -> ../lib/firefox/firefox

Aha. Sure enough, all I had to do was move /usr/lib/firefox to /usr/lib/firefox1.5, and move my new firefox dir to /usr/lib:

% sudo mv /usr/lib/firefox /usr/lib/firefox1.5
% sudo mv ~/downloads/ff2/firefox /usr/lib/

While I understand that it is a free product, and while I am very pleased with many aspects of Firefox, and while I understand that Linux is a niche market, their end-user documentation leaves a little to be desired.


Review: DeMarco and Lister's Programmer performance and the effects of the workplace

Posted in programmer productivity, review at 5:12 pm by ducky

I got started on looking at productivity variations again and just couldn’t stop. I found Programmer performance and the effects of the workplace by DeMarco and Lister (yes, the authors of Peopleware). The paper is well worth a read.

In their study, they had 83 pairs of professional programmers work all on the same well-specified programming problem using their normal language tools in their normal office environment. Each pair was two people from the same company, but they were not supposed to work together.

  • They found a strong correlation between the two halves of a company pair, which may be in part fromcorrelation of productivity across a company
    • a pretty stunning correlation between the office environment and productivity
    • (or perhaps due to different companies having radically different tools/libraries/languages/training/procedures, which they didn’t discuss)
  • The average time-to-complete was about twice the fastest time-to-complete.
  • Cobol programmers as a group took much longer to finish than the other programmers. (Insert your favorite Cobol joke here.)

productivity differences

Over and over, I keep seeing that the median time to complete a single task is on the order of 2x to 4x times the fastest, not 100x. This study seems to imply that a great deal of that difference is due not to the individual’s inherent capabilities, but rather the environment where they work.

Review: Dickey on Sackman (via Bowden)

Posted in programmer productivity, review at 4:17 pm by ducky

To reiterate, there’s a paper by Sackman et al from 1966 that people have seized upon to show a huge variation in programmer productivity, a paper by Dickey in 1981 that refuted Sackman pretty convincingly, and an article by Curtis in the same issue as Dickey’s. I didn’t talk much about the Dickey paper, but Tony Bowden has a good blog posting on the Dickey paper, where Dickey reports on a more reasonable interpretation of numbers from the Sackman’s data.

(Basically, Sackman compared the time it took to complete a task using a batch system against the time it took using a timeshare system. This was interesting in 1966 when they were trying to quantify the benefit of timeshare systems, but it’s not good to look at those numbers and say, “Ah, see, there is a huge variation in programmers!”)

Because I like making pretty histograms, here are the Sackman numbers via Dickey via Bowden — the way they ought to be interpreted. These show the time to complete for two tasks, the “Algebra” task and the “Maze” task.

The small sample size hurts, but (as in the Curtis data and the Ko data) I don’t see an order of magnitude difference in completion speed.

Goodbye, Chief.

Posted in Random thoughts, University life at 10:16 am by ducky

Today, my alma mater, the University of Illinois, announced that Chief Illiniwek would no longer perform at athletic events.

The Chief’s performances had been hugely divisive, with one side contending that the Chief was offensive to Native Americans and the other insisting that his portrayal demonstrated respect for Native Americans. Both sides were correct, which made it so very difficult.

The Chief was not a mascot. He didn’t stand on the sidelines and lead cheers, he didn’t clown around, he didn’t mug for the cameras, or throw t-shirts into the audience. He came out at halftime, danced, and left. He comported himself with dignity and gravity at all times. The dance was physically very challenging. The students respected and honored the Chief. It was very respectful, compared to what it could have been.

On the other hand, the Chief was not authentic. The dance, while containing some elements of Native dances, was not totally authentic. In particular, the last thing the Chief did before leaving the field was mid-air splits — jumping up, spreading his legs up and out in a V, and touching his toes. The costume was Lakota, not Illiniwek. (The Illinois Natives were pretty efficiently disposed of, so there aren’t a lot of records of what they wore or how they danced.) Furthermore, it is a strange borrowing to put Native culture into this context.

What pushed me over to the anti-Chief side was to think about how I would feel on seeing a bad adaptation of important Western culture out of context. Imagine that you’re at a soccer game in Japan, and at halftime, they announce that it’s time for The Pope. Imagine the crowd going wild as a guy in Greek Orthodox regalia solemnly runs out onto the field, and does something sort of like an Irish jig, ending with mid-air splits. Even as a non-Catholic, that would make me highly uncomfortable and perhaps a bit angry. If I were Catholic, I’d be furious.


Review: Robillard's How Effective Developers Investigate Source Code: An Exploratory Study

Posted in programmer productivity, review at 6:18 pm by ducky

(See my previous programmer productivity article for some context.)

Martin Robillard did a study in conjunction with my advisor. In it, he had five programmers work on a relatively complex task for two hours. Two of the programmers finished in a little over an hour, one finished in 114 minutes, and two did not finish in two hours:

Robillard carefully looked at five subtasks that were part of doing the main task; there was a very sharp distinction between the three who finished and the two who did not. The two who didn’t finish only got one of the subtasks “right”. S for “Success” means everything worked. I for “Inelegant” means it worked but was kind of kludgy. B for “Buggy” means that there were cases where it didn’t work; U for “Unworkable” means that it usually didn’t work; NA for “Not Attempted” means they didn’t even try to do that subtask.

Coder ID Time to finish Check box Disabling Deletion Recovery State reset Years exper.
#3 72 min S! S! S! S! S! 5
#2 62 min S! S! S! S! B 3
#4 114 min I S! B S! B 5
#1 125 min (timed out) S! U U U NA 1
#5 120 min (timed out) S! U U NA NA 1

Because coder #1 and coder #5 timed out, I don’t know how much of a conclusion I can draw from this data about what the range of time taken is. From this small sample size, it does look like experience matters.
This study did have some interesting observations:

  • Everyone had to spend an hour looking at the code before they started making changes. Some spent this exploration period writing down what they were going to change, then followed that script during the coding phase. The ones who did were more successful than the ones who didn’t.
  • The more successful coders (#2 and #3) spread their changes around as appropriate. The others tried to make all of the changes in one place.
  • The more successful coders looked at more methods, and they were more directed about which ones they looked at. The second column in the table below is a ratio of the number of methods that they looked at via cross-references and keyword searching over the total number of methods that they looked at. The less-successful coders found their methods more frequently by scrolling, browsing, and returning to an already-open window.
    Coder ID Number of methods examined intent-driven:total ratio Time to finish
    #3 34 31.7% 72 min
    #2 27.5 23.3% 62 min
    #4 27.5 30.8% 114 min
    #1 8.5 2.0% 125 min (timed out)
    #5 17.5 10.7% 120 min (timed out)
  • From limited data, they conclude that skimming the source isn’t very useful — that if you don’t know what you are looking for, you won’t notice it when it passes your eyeballs.

Family mission statement

Posted in Family, Married life at 11:34 am by ducky

Before nephew Yeshe came to live with us for year, my husband and I talked a bit about getting his buy-in on how the family should run. Being Silicon Valley corporate geeks, we wrote a mission statement for our family:

Family is a happy place where everyone works together to help each other achieve their goals.

Yeshe came and went, but the mission statement lives on. I really like it, and am really glad we sat down and wrote it out.


Snow, flooding, rock slides, laryngitis

Posted in Canadian life, University life at 10:51 pm by ducky

I gave a talk last week at Web Directions North that I didn’t get to rehearse as much as I’d wanted due to snow, flooding, a rock slide, and laryngitis.

Snow: This might not sound like a biggie, but the Annual Green College Ski Trip happened on Feb 3 and 4. I had been ignoring my husband for days on end as I worked on my presentation, and I couldn’t really spend the domestic credits that it would take to skip the trip.

Flood: While Jim, I, and 26 other residents were on the ski trip, one of my neighbor’s sprinklers failed and gushed water into his room for 40 minutes before the firefighters and residents got it shut off. (Yes, we collectively are looking into the emergency procedures around here.) While our room ultimately had no water damage, nobody knew if they other sprinklers were also going to go off or not, or if the water would leak into our room.

Resident Mika McKinnon, who impresses me more and more as time goes on, basically took charge and organized posses of people to go into neighboring rooms (via the we’ll-let-you-back-into-your-room-if-you-get-locked-out master key holders), unplug all of our electrical appliances, and take laptop computers out and to hold them in a dry place.

Note that they had zero legal right to do this. If I wanted to, I could probably sue them up one side and down the other for breaking and entering, and trespass to chattels if not outright theft. And yet, they had absolutely every moral right to do so. As Mika’s father is a lawyer, I presume that she realized that she could get in legal trouble for doing so, yet did so anyway. I greatly admire her for that, and I am very grateful to her and all the others for rescuing our laptops.

Rock slides: On Sunday, the day we were supposed to come back from the ski trip, a rock slide closed the only road back to home for eight hours. This meant that we got back late. Not only did that mean that I didn’t get Sunday evening to rehearse, but tapping lightly on the door of the guy who had our laptops failed to rouse him. It took another day to get our laptops back.

Laryngitis: On Tuesday evening, my co-presenter emailed me to tell me that he had lost his voice. It looked like maybe I would have to give his presentation and mine… and while I knew about some of his stuff, there were some detailed technical issues that I didn’t actually know anything about. So I tried to cram knowledge about his area.

Fortunately, his voice came back by Thursday, so I didn’t have to give his talk.

My talk went okay. I got some trustworthy feedback that at least some people liked it, but it wasn’t nearly as polished and professional as I am capable of. Next time.

« Previous entries Next Page » Next Page »