Month: February 2008

A new use for that Boingo subscription

I have a monthly Boingo subscription. It was mostly so that I could get online at Logan, back when I was flying out a few times a month (or, week) without having to pay $6.95 a shot. I’m not traveling nearly so much for my new job and was considering cancelling—until I saw the news that AT&T is taking over the Starbucks hotspots from T-Mobile.

Since AT&T is a roaming partner of Boingo, I’m thinking about keeping the subscription. Prepaid high-speed at any Starbucks for my iPhone sounds like a pretty good plan.

Where are my feet?

It’s cold, cold, cold here today. Really unsettled weather over the weekend; it went from somewhat reasonable and sunny on Saturday to rainy and thundersnowing on Sunday. Twice we went out shopping in clear weather only to look out the window inside the store and see lightning and heavy, wet horizontal snow whipping across the parking lot. The winds were high and blew in 6° air from somewhere. It was too cold even for the dogs to walk, and that’s saying something.

Feeling like a copier

Great product manager joke from Art Petty (via Steve Johnson at Pragmatic):

Q: Why is a Product Manager like the Office Photocopy Machine?

A: Because when it works no one notices and when something goes wrong, everyone wants to kick it.

Heh. Heh. TANJ, indeed.

Of course, many a product manager has done the “Danse Russe” (“I am lonely, lonely, I was born to be lonely, I am best so!”), but I’ve found an interesting dynamic working as the second product manager at my company. In addition to the extra pair of hands to manage the workload, there is some reinforcement and validation. Of course there’s always the danger that that turns into “us vs. them,” so that is something to watch. But it really does help having a sanity check on team interactions, process questions, requirement prioritization, and all the other caution areas that product managers face.

Agile and the Iron Triangle of Software Requirements

Software companies make fundamental tradeoffs between cost, quality, and functionality (the Iron Triangle) all the time. These tradeoffs happen in the software itself, of course, as anyone who’s ever heard this analogy will tell you. But they also happen in the process of making the software. In software development processes, cost = effort, resources, and time, and functionality = functionality, of course. But what is quality?

I don’t mean this to sound like a Zen primer or a TQM discussion, but software quality is much more than the negative condition of having no open bugs. It’s also the positive condition of building the right thing. Generally speaking, this means product strategy and product requirements. And here is where the arguments usually start, because it’s far from clear how to build The Right Thing. Traditional software development tries to ensure that The Right Thing gets built by requiring a multi-stage sign off and by providing extremely detailed documents at each stage of the process—a marketing requirements document for initial concept sign off, followed by a functional requirement, a technical requirement, a detailed test plan, and so forth. Between each of those stage gates is a lot of work. Many months may pass between initial concept and development.

So using rigorous stage gates to build in “quality” comes at a cost, especially in time. This is particularly risky in a new market space, where time to market and time to benefit is key. If you commit to a lengthy waterfall process, you lock yourself into a feature set that commits the team to a path of several months or even years to build the Right Thing.

But in a year’s time, the market may have shifted out from under you, and not just once. Clearly a way of building software is needed that doesn’t require so heavy a use of resources to define requirements and that can allow the Right Thing to be built more quickly, and that allows for more opportunities for the team to “change its mind” without wasting a lot of work. Agile software development methodologies seek to provide those opportunities by defining the work product to be built in terms of “iterations,” where the software gets built in discrete, short sprints rather than one. Something concrete gets built in each iteration, but the team is free to change its mind about what to build in the next iteration—and it may need to, either in response to feedback about the product of an earlier iteration, or because things have changed in the outside world.

To support a rapidly iterating software product, though, you need a requirements process that moves quickly as well. That’s where Agile gets its emphasis on “stories.” An Agile story is a simple way to specify a requirement, and it follows a pattern of “As a user type, I want to do something because of an important reason.” It’s a streamlined but easy and effective way to specify functional requirements. The idea is that each story is a standalone piece of functionality that delivers value to a user. Therefore, every discussion about choosing features for a release discusses trades between things that actually benefit the user, which is a much easier decision to make than choosing between a functional requirement and a technical requirement.

As you might guess, adopting Stories as a requirements methodology has its own challenges. In this case, the tradeoff between requirements “features” (detailed documentation) and requirements “quality” (preserving flexibility by not overspecifying) has real downstream impacts on other parts of the organization. For instance, Marketing teams are used to using the MRDs for product features as input to their messaging campaigns. And every team in the organization misses the stage gates as a chance to come in and provide feedback about what is to be built. So the challenge becomes how to build a process that remains flexible and adaptable, doesn’t get in the way of the participants, and ensures that the right deliverable gets built and brought to market correctly.

There are some pretty good suggestions out there on how to do this, as it turns out. Googling agile and mrd gets you a variety of good discussions and ideas, including the following:

  • Only write an MRD when you need to (Luke Hohmann)
  • Let your prototype be your requirements doc when you can
  • Demo each “sprint”’s results to everyone in the organization while sharing the prototypes for the next iteration (both from SVPG)
  • Keep your requirements at one level. Don’t write high level requirements documents that are then translated into low level documents. These are a good example of Conway’s Law (Roger Cauvin)
  • Use a quick 10-question checklist as a way to structure an opportunity assessment (SVPG again)
  • Minimize the impact of your iterations on your users by communicating with them (SVPG once again)

I will try to expand on some of these topics in future posts.

The Good Old Song of … the Virginia Glee Club

Funny what you find when you dig through University archives. I was going through some old Virginia Glee Club photos tonight when I decided it would be a good idea to actually read the lists of names at the bottom. Some familiar names popped out (Ernest Mead, Harry Rogers Pratt), and then one (in an 1893 photo) that sounded familiar but I couldn’t place it. E.A. Craighill…

Then it hit me. Here’s the guy credited with writing the lyrics to “The Good Old Song” between 1893 and 1895—in an 1893 Glee Club photo! The guy who wrote the freakin’ “Good Old Song” was in Club!!!!

Well, I was having trouble filling out the Notable Alumni section of the Glee Club article after Woodrow Wilson… now I’ve found Notable Alum #2.

Super Tuesday hangover

Super Tuesday has come and gone. While it appears to have done what the parties wanted on the Republican side by narrowing the field down to one presumptive winning candidate (though McCain still has a resurgent Huckabee nipping at his heels in the South), the Democrats appear to be no closer to reaching a decision.

Two interesting things I observed locally. First, turnout: according to the numbers reported by the Globe, 18,027 people voted in Arlington (my home town) in the primary. As of 2006, Arlington had 28,022 registered voters. That’s something like 64% of the registered voters turning out for a primary. People are motivated here.

And they’re motivated to do more than build a horse race between two candidates. The Globe’s numbers included a nontrivial number of people who voted for candidates who had already dropped out of the race, including Edwards and Kucinich. While there’s no doubt that a large number of those were people who voted absentee before the candidate withdrew from the race, I have anecdotal evidence that that isn’t all that is going on.

I spoke to an Edwards supporter last night who said that, while he had voted absentee before Edwards withdrew, he would have voted for him anyway and he knew quite a few other Edwards supporters who were planning to do the same. Their reason: they were indifferent between Obama and Clinton, and wanted the party to consider Edwards’s platform issues at the convention, particularly his stance on poverty.

2008 is shaping up to be a very interesting election indeed.

Automated application testing has deep roots

My current employer is built around a couple of concepts: certain kinds of needs are better served on demand than by buying a tool, and certain kinds of software testing (in our case, application security testing) can be automated. There are other concepts that come into our business model, but those are kind of at the core of what we do.

Like so many other things in the world, our concepts aren’t new (though we do have some unique tricks that make them uniquely valuable). Automated testing, in particular, has a long lineage. I didn’t realize how long, however, until I came across a reference to MonkeyDA on Andy Hertzfeld’s Folklore.org, a collection of stories about the creation of the Macintosh.

MonkeyDA was a Desk Accessory, a tiny program that could be run without forcing another program to quit. (Desk accessories were a response to the lack of multitasking in the early Mac OS, and the many use cases of working with a modern graphical computer that essentially demanded having two programs open at once. They ran on top of the currently running program in a different memory space.) But it was a “special” DA. It simulated user interactions with the Mac, by feeding a random stream of events to the OS resulting in the cursor moving on the screen, text being typed, menu items being selected, etc. It was kind of designed to see if it could break the Mac OS or its applications by subjecting it to all sorts of abuse—just like a monkey banging away at the keyboard and mouse would. If the program crashed, it meant the Monkey had found a condition that a user might eventually find. The Monkey is no substitute for human testing based on test cases, but it’s an important complement.

The punch line, of course, is the size of the Monkey program. Written back in October 1983, its binhex is only 2791 characters long. That’s less than 3K of compressed code. That you could create that much mayhem with that small a program is a reminder that code has power, and that you never know what someone else’s code is going to do.

Roundup: the Tin Man speaks; JP Makes, Dave nails it

The Tin Man’s voice is in the New York Times. I mean, they have an actual sound clip of him being interviewed about the Democratic presidential candidates. How cool is that? It gives “voice of the blogger” a whole new meaning.

And I’ve been meaning to post about JP’s other career for a bit as well. He’s the only animator, and UVA alum, and friend, I have who writes for MAKE Magazine. I really dig the Lego Recharging Station.

Finally, I suppose I would be remiss to not point out Dave’s extended post on philosophy in sports, which says a lot of the things that I wanted to say yesterday. Particularly this paragraph:

Losing teaches you that there’s more to life than winning, and that’s the best lesson possible and it’s the one lesson you keep needing to learn over and over until you lose everything, which like it or not is what we all do in the end.

Getting Things Done with Outlook 2007, revisited

A while ago I posted a few things that I found about implementing the GTD methodology with Outlook. Since I recently changed jobs, I’ve had an opportunity to carry some of the best practices forward as well as start from ground zero (a true Inbox Zero!) in some other areas. Here’s a quick roundup of what I did on my brand new inbox to facilitate maximum productivity.

The very first thing I did was to download and install Taglocity, which has saved my bacon so many times. I don’t know why people who design software to manage large volumes of information don’t get this, so I’ll just say why I find this so superior to the built-in Categories feature: it is much much faster to type in multiple tags for an inbound email than it is to make multiple mouse movements to pick multiple categories from a list. It’s fundamentally the same principle as why Keyword Assistant is absolutely necessary with iPhoto (at least, pre-2008). Email may be full text searchable, but from an actionability standpoint it’s just as opaque as photos until you give it context through tags. And the more tags, frankly, the better. All the UIs that assume that you’ll only be assigning one or two categories or tags are fundamentally broken because they don’t help solve the problem of how to find something later.

The second thing I did was to create exactly one sub-folder in my Inbox, called _archive. The underscore is a habit; it’s left over from when I had a billion subfolders and wanted to be sure my Archive folder bubbled to the top of the list.

The third piece was adopting the discipline that I’ve learned from practicing a little (a very little) GTD:

  1. Scan each mail for actionability.
  2. If it’s calendar related, triage it (right now that means “accept it” but a more complex triage process is required as my calendar actually gets full).
  3. If it’s a task, do it quickly (< 2 min) or tag it and add it to the task list.
  4. If it’s useful reference, tag it and add it into the archive.
  5. If it’s none of those things, delete it.

Lastly, I set up a few smart folders: Tag folders (smart folders that look at categorized items across all my mailboxes, created through Taglocity) for all my projects; a smart mailbox for Unread Mail and for Unread or For Follow Up items. Today, I added one other smart mailbox—items in my inbox that weren’t flagged, meaning that they hadn’t been processed or moved to the task list. I also set up a custom Shortcut bar and added task age to my To Do list view. The last three items were based on the helpful advice from David Ornstein in this blog post.

Some stuff I might try to do in the future: custom button bars based on the posts by Simon Guest (and again) and Omar Shahine, and maybe tweak some of my task creation settings based on the advice by Melissa Macbeth.

And what has fallen by the wayside? The Hipster PDA was cool for about five minutes. I’ve graduated, on those occasions where I don’t have my laptop, to a little Moleskine notebook. But increasingly everything goes directly into Outlook. Likewise, I’m not bothering with the customized Project form hack mentioned in the same old post; it never worked well enough under Outlook XP for me to try bringing it forward into Office 2007.

And I’m on the edge about Google Desktop; while I was hooked on it before, I’m starting to think critically about the tradeoff between security and functionality that it provides, and I’m not sure I like the conclusions I’m drawing. More later.

Boston gets philosophy again

As Dave Winer would say, it’s philosophy time for Patriots Nation. What a heartbreaker of a game last night. But it was that rare Superbowl, one that was exciting to watch from beginning to end, and for that I thank both the Patriots and the Giants.

Yeah, I thank the Giants. Now maybe Brady can get his feet back on the ground and his head back to the game. I think the last two weeks of preemptive crowning of the team in the media were not good for the play last night.

I’m really grateful to the Pats, too, who gave us an amazing ride all season long. I don’t expect to see this kind of season again, but now I’ll always hope.

VW Passat coil packs: How not to get return customers

I was driving my 2003 Passat home from the office on Tuesday when something weird happened: the car started idling very rough at a stoplight. I haven’t had a car run that rough since the days when I was driving my 1977 MGB. I thought that perhaps I needed to get a tuneup. I did what I used to do on the MG: put the car in neutral and bring the engine speed up. That calmed the idle a little bit, but when I started driving it past the light the problem came back. Then the check engine light came on. And started flashing.

At that point, I should have pulled over and turned off the car, but I was less than a mile from home so I nursed it there and parked it. Then restrained myself from kicking the car.

The rough running turned out to be caused by misfires in two of my four cylinders; when I got the car home I was only running on two cylinders. I was without the car for two days while the dealer replaced two ignition coil packs that had failed and reprogrammed the car’s computer. To my relief the bill wasn’t exorbitant, but it makes me wonder whether the other two coils are due to go too.

The capper is that I happened to look up Volkswagen Passat in Wikipedia, and found this lovely piece of text for the Mark 5 version:

A common problem that arose along with the introduction of the 2001.5 “B5.5” models was a common failure of ignition coil packs. This problem applied only to owners with the 4 cylinder 1.8T engine, whose coil packs are marked with the part number “06B 905 115H”. The solution is a simple swap of the coil pack for a newer version, a minor repair in both time and cost.

The article even cites a very detailed page on MyLemon.com about the problem, which apparently mostly affects late 2002 and early 2003 models. My car was one of the first 2003s.

So the question is: why hasn’t Volkswagen issued a recall of these cars?