Technical skill set for product managers

We’ve been working on hiring a product manager here at Veracode, and it’s gotten me thinking about technical literacy.

The one thing you don’t want in a product manager is someone who thinks he can write the code better than his/her developers. That sets up a major problem with boundaries–you want the product manager to worry about user experience and whether the customer’s business need is being fulfilled, not whether the developers are implementing the feature the way that he would.

But you also don’t want a product manager who’s technically illiterate. That way lies unrealistic feature requests and their cousin, unrealistic customer commitments; communication breakdowns; and overreliance on engineering for decision support.

I think there’s a middle ground: a set of technical skills that the product manager will use to do his own job, and that will help him communicate better with his engineers, without getting into their business.

In my client-server days, the skill set might have included (in addition to normal technical literacy, e.g. ability to run Office apps):

  1. SQL
  2. Excel pivot charts
  3. Windows batch scripting

These days in the SaaS world, it seems like the skill set might be:

  1. Basic statistics
  2. XSLT
  3. Excel pivot charts
  4. CSS
  5. SQL (it never goes away!)

What’s your favorite technical skill that you use all the time as a product manager?

Apple iPad: first reactions

Four reactions that I agree with (parts of) in response to Apple’s iPad announcement yesterday:

  • Doc Searls places the iPad in the context of vertical integration (apps all the way down to CPUs) and horizontal playing fields and says, “What you have to appreciate, even admire, is how well Apple plays the vertical game. It’s really amazing. What you also have to appreciate is how much we also need the horizontal one. The iPad needs an open alternative, soon.”
  • Dave Weinberger says that the iPad is the “future of the past of books” and says it’s missing interactivity and collaboration as key features.
  • John Gruber says that the iPad user experience feels like it’s all about speed, and says that Apple’s vertical integration play (the aforementioned Apple A4 chip) is responsible, and that “this is Apple’s way of asserting that they’re taking over the penthouse suite as the strongest and best company in the whole ones-and-zeroes racket” ahead of Sony, Nokia, and Samsung.
  • Michael at Cruftbox sums up the reactions of the rest of the world and says, “You’ll bang on about features, data plans, DRM, open source, and a multitude of issues. You’ll storm the message boards, wring your hands, and promise you won’t buy one till ‘Gen 2.’ The din will grow and grow as time passes. And then one day, in a few months, you will actually hold one and use it. And you will say, ‘I want one. Iwant one right now.'”

I think what disappointed me about the launch was not the device but the position it occupies. Jobs sees the iPad as occupying empty space in the consumer world between a PC (laptop) and phone. And there is probably room in that position. But the iPad seems also to be firmly positioned, at least for now, as a companion device. You sync it to another computer over iTunes. There’s no USB port or optical drive. It’s not going to be replacing anyone’s laptop any time soon.

And, frankly, that’s what I was hoping it would do. Because while it looks like it blows away its target use cases (web browsing, mail, calendar, gaming, music, book reading, even office apps), there are some very real use cases it doesn’t handle. And not just being a development platform. Like:

  • Preparing taxes (though Intuit could probably do a tax application for it)
  • Scanning documents (no USB port…)
  • Printing (ditto–though I wonder if it supports network based printing?)
  • Videoconferencing (no camera and no ports)
  • Organizing photos
  • Making a calendar or Christmas card

Additionally, I have question marks about some of the use cases that it seems to handle well otherwise. Like: can I point its version of iTunes at my 500 GB network drive and play music from there? How do the new iWork apps manage their files? (Remember, there is no user visible file system on the iPhone OS, on which the iPad is based.)

But, my quibbles aside, I have to confess that I’ve already talked with my wife about getting one. We’re pretty excited for the brave new iPad future. Because for most of what it does, it does beautifully.

The food court model of capacity planning

hmart

I just got back from the craziness that is the opening week of the new H Mart in Burlington, MA. It was instructive on several levels, not least of which was the personal (note to self: wait three weeks after the opening of a new highly hyped destination before attempting to visit). But there were also some business lessons in capacity planning to learn.

I was curious about the supermarket’s general offerings — always happy to find a new place to get specialty vegetables like galangal and lime leaves, and the prospect of picking up a carryout pint of kimchee fills me with something like culinary concupiscence (Korean takeout being thin on the ground in the northwest Boston burbs). But this visit, at noon on Monday, was about the other big letters on the sign out front: Food Court.

Takeout options are thin on the ground in this part of Burlington, with only a handful of places (Ginger Pad, Fresh City) within walking distance of my office, and only one or two more (Panera) within a reasonable drive. So I was excited that a new prospect was available. And I wasn’t the only one. When I parked (and the amount of time it took to do that should have been a warning flag) and got inside, I saw the big food court, about six counters in all covering various Asian cuisines, packed full of people. I parked myself in the line at the end for Korean food and waited.

And waited.

And waited.

There were some real operations problems happening behind the counter. The wait time to place the order was about twenty minutes, and when I got to the counter I found that about half the selections were marked as unavailable (“No pork,” the harried cashier explained). Average order fulfillment start to finish was on the order of thirty minutes or more, with about ten of that cooking time. The rest was consumed with waiting for someone to pack the order and get it out, a problem exacerbated by un-bussed trays and dishes, only two visible line cooks, and short supplies.

H Mart had, famously, months to get ready for the launch. How’d they goof it up? Chalk part of it up to opening week snafus, perhaps. But easy things like staffing the counters should have been solved problems by four days into the process. I think the real operational lesson is that H Mart neglected to anticipate all the potential sources of demand for its offerings. They didn’t have visible staff problems or lines elsewhere in the supermarket, and even had fully staffed demonstration tables nearby. What they didn’t count on was a large number of office workers eager for a new lunch option. That left-field demand spike apparently swamped their available capacity of workers and their foodstocks.

The general lesson? When doing capacity planning, consider all the possible uses of your service and think day by day and hour by hour how they will be consumed. Then ask: am I ready?

The death of tr.im, or why you are your own product manager

The recent flap over the impending death of tr.im reminds me of a discussion I had at the Berkman Center when I crashed one of their meetings back in 2004. The question was, do you use external services with your blog? That is, do you host your images on Flickr or a related service? Do you outsource comment management? These days, the question is do you host your own videos or do you let YouTube do it; or do you use a URL shortener.

Fundamentally, these are strategic questions like the ones that product managers face every day. The question is “Build, Buy, or Partner?” and it’s a question about how you add functionality to your product offering. In this case, the “product offering” is your public presence on the Internet–which is to say, in public, on-the-record discourse. As the question is conventionally understood, “build” means build it yourself, “buy” means acquire the functionality via some sort of purchase of rights, and “partner” means make a business arrangement where the partner delivers the functionality directly. In web development terms:

  • Build: You can build most of the functionality that people use on the web, from photo galleries to URL shorteners, yourself if you are a reasonably competent programmer.
  • Buy: You are acquiring via a license (even a free one) functionality from a third party and providing that functionality to your users. Can include purchased software or free software, whole packages or plugins.
  • Partner: You are using third party services directly–embedding photos and video from someone else’s server, using a third party URL shortener, etc.

So how do you decide to build, buy or partner? You can ask yourself the same questions that product managers everywhere ask:

  1. Do I have the capability to create this functionality?
  2. Do I want the responsibility of maintaining this functionality and adding to it over the long run?
  3. Is this functionality a core part of what I do? Do I derive some sort of competitive advantage from it?
  4. How much control over the final product do I want?
  5. Can I afford to have the content go away?

If you can do #1 but not #2, buy might be a better option than build. If the answer to #4 is “a lot”, partnering is not an appropriate option.

Let’s look at some people’s reactions to the event in this light:

Dave Winer had chosen the “partnership” model with tr.im (in the sense described above, that he is using their services and building atop them), building a lot of functionality on top of their APIs. He sees tr.im’s collapse as an argument to eliminate URL shorteners altogether, or at least to require that they provide a portability option. Portability is a way that you can escape Question #5, a safety clause if the partner goes out of business or if you don’t like what they’re doing with your content. I think that shortened-URL portability is in this analogy the equivalent of source code escrow and other safety provisions in conventional software contracts–it’s your escape hatch to make sure your personal data isn’t threatened. This is a perfectly sane request if you’re entering a real partnership relationship, where you’re adding value to the other party’s offering.

By contrast, Jeffrey Zeldman went the “buy” path, installing a WordPress URL shortening plugin to share pointers to his own content. For him, having short links to his content that work indefinitely is too important to risk having “the third-party URL shortening site [go] down or [go] out of business.”

Looking at it through the build-buy-partner lens, it’s also easy to see why WordPress has become such a dominant platform. The ability to add third-party developed plugins to add functionality provides a wide variety of options to add new functionality and allows you more options than simply blindly partnering with another organization, without any assurance that they’ll continue to support you.

Why go down this path at all? Why worry about the longevity of what are almost certainly transient services? One way to look at it is this: at the end of the day, your web presence is your product, and you are its product manager. You are responsible for the strategy that determines how the world views you. And in that light, it makes sense to borrow some strategies from product management to plan that strategy. Others use the formulation “You are your own CEO”; as your own CEO, consider that what people interact with online is not you but a product.

Creating a drama-free zone in product management

If there’s any doubt that management skills are portable across industries, consider this: one of the most valuable organizational traits that carried the Obama team to victory in 2008 is one of the most valuable factors for success in product management. I’m talking about the ability to create a “drama free zone,” and the ability to do it convincingly can make or break you as a product manager. Here’s two real scenarios I’ve seen this week that underscore the point.

Scenario #1: “Where’s Feature A? We’ve been asking for it for a year? Why the hell haven’t we built it yet?”

You know this one. Someone’s pain point, which is perfectly valid, simmers along until one day it explodes. Only problem is that this is the first time anyone has mentioned Feature A in a long time, and certainly it didn’t come up in the last roadmap planning discussion.

Solution: The response can be heated–“why the hell didn’t you mention this six months ago?”–or it can be drama free. “Hey, I understand there’s a customer pain point here. Let’s look at the priorities we’ve got and understand where this fits in. Is this more important than our planned work in the next release? If so, that’s where it belongs. If not, then we all agree it can wait.”

There are three steps here: acknowledge, align, act. The first step is to acknowledge that the other person has valid reasons to be upset while shifting the discussion to the common interest–the customer–and introducing an objective measure, the priority. The key is focusing on the external, objective issue — the priority of the request — rather than getting into heated discussions. (Obviously it is easier to do this if you are using stack-ranked user requirements.)

Scenario #2: Suddenly four email threads pop out of nowhere regarding a longstanding customer pain point that has apparently reached crisis proportions for no particular reason. “Feature X is broken! We need to fix it!” goes up the cry. You, as the product manager, know that the apparent failure of Feature X is really a mishmash of legal and contractual issues coupled with a lack of Feature Y and Z. But management insists that the answer is to fix Feature X, and now four separate groups of people are trying to find things to fix in it (and generating long email threads).

Solution: The response should be comprehensive, quick, and above all drama free. It’s natural, as a product manager, to want to fly off the handle when there are so many people digging into an issue. But a quick, dispassionate, thorough response (“Here’s what we know, here’s what we’re going to do about it, and here’s what’s still unknown and our next steps to find out”) has benefits in that it acknowledges the problem, communicates that there are multiple issues, and lets the assembled parties know, to return to our Obama metaphor, “Everybody chill out: I got this.”

What are your favorite drama-free problem solutions? Conversely, are there cases where engaging in drama makes a positive difference in your work as a product manager?

I’m alive

I apologize for the plethora of linkblog posts here over the past little bit, and for their relative paucity. It’s been a busy few months. I got a new boss and transitioned from a “second product manager” to more of a lead role, at about the same time that we launched a set of significant initiatives (c.f. press release if interested, if not, c.n.f.). We launched last night, a day after I got back from a holiday visit to my in-laws, and two days into the rehearsal cycle for the last Boston concert of the 2009-2009 Tanglewood Festival Chorus season, the Berlioz Te Deum.

Like I said: busy.

Not too terribly bad, though. I’m batching it for a few days and enjoying the ability to just sit and catch my breath. Did you know that there’s this thing called television? And that, mercifully, Google Reader maxes out at reporting “1000+” unread items?

The best requirements prioritization scheme EVAR.

I thought I had seen every possible permutation on the problem of how to prioritize requirements. Then the engineers at my company came up with a new one: the pony priority.

Is “pony” an acronym? Nope.

It’s the lowest priority there is. It’s the “I want a pony! No, you can’t have a pony” priority. Or as the classic image has it:

pony

This priority is properly reserved for requirements that would be, like, REALLY KEWL but that won’t ever be implemented. Because they’re unsolved research problems, or because they would cost more than the whole company is worth.

This is a seriously useful concept. It provides a way to say, “I recognize the value of the idea, but we can’t do it no matter how much you try.”

Do use it in your own company and let us know it works out.

Roadmaps in Agile, part 1

As a product manager in an agile development model, one of the most difficult things to do is building a roadmap. This is because making feature commitments for six to nine months out feels contrary to the spirit of being “agile” and maintaining flexibility to change course to support the needs of the business.

Why is having a roadmap when you’re agile so hard? One word: sales. It’s relatively easy (provided you know how to do it) to move requirements around when the only people you’re communicating with are internal stakeholders. It’s much harder when a sales guy has already told the Big Prospect that the frimfram feature is going to be added in third quarter, based on a roadmap that he saw six months ago. Sales cycles have their own momentum, they have their own set of unforeseen requirements that weren’t planned for, and they’re very hard to sync up with a roadmap that’s moving to respond to current and future needs of the company and customers.

So how do you do it? There are three important dimensions to any roadmap, and those are priorities, cost/benefit, and time. Getting the first two properly defined is critically important; once you have that, distributing the roadmap across time is more of a mechanical exercise (but not without its hazards). First, though you have to know:

What do we need to do? If you’re a product manager who documents every requirement you ever unearth from a customer, prospect, sales guy, internal operations perspective, or executive, stores it in a backlog, and periodically revisits the backlog to organize and categorize it, this step might actually be relatively easy. If not, it will require some legwork–talk with each stakeholder, make sure customer voices are represented through input from the sales force (and/or SalesForce), write everything down, send the list around and make sure that nothing got missed.

What do we do first? Prioritization has to be done as a conversation; there’s no way around it. You can do prioritization in a vacuum if you’re using a static set of priorities (high, medium, low, for example), but if you’re stack ranking your requirements (which I firmly believe is the best way to go) you need the appropriate stakeholders to get together and make the tradeoffs. To do a good job in stack ranking, it helps to set some ground rules (e.g. the requirement contributes to current revenue, builds groundwork for future revenue, or reduces operational costs) and set some rules about how those translate into ranks (e.g. current revenue more important than future revenue). There are some finer dimensions to the problem; generally there are different types of requirements and different types of people who will work on them, so if you slice the prioritized list by those dimensions do the priorities still make sense? (They should.)

What’s the cost and benefit? Ideally this should be done before prioritization, since it informs it, particularly the benefit part. If you have a major initiative that’s supposed to drive new business, someone should be able to estimate how much new  business it will drive. Engineering requirements can be estimated by cost. Combining the two can help to drive prioritization. It’s important to know the details of the business model behind the requirement, too. If the revenue plan for the requirement assumes that it will help to drive revenue for two quarters, it had better be released by the middle of the year.

When do we do what? Here’s where the rubber hits the road. Up until this point, it’s better to deal with requirements as high level objects–epics of work that can span multiple teams and releases. But to actually assign features to releases, you need to be able to at least guess at a high level division of work (we’ll work on this for three release cycles before it becomes available to the public) and of responsibility (both teams A and C contribute, so we need to put something in both team’s work plans).

The reason that time based planning is trickier, too, is that it needs to make explicit assumptions about certainty. You can do a pretty concrete plan for releases early in the calendar year, because you know that the business requirements won’t change too much between planning time and the release date. But the back half of the year is far trickier. So each release during the year needs an increasing “change reserve,” unallocated capacity that can take on new requirements. Alternatively, management has to be comfortable with the proposition that the out quarters will be highly subject to change.

Once you’ve done the basic blocking and tackling, the real fun begins: how do you communicate this nuanced plan in a consumable format to management and sales? Well, that’s part 2.

Macworld Keynote 2009

It’s not going to be a Stevenote (and on that note, best wishes to Steve as he gets his hormones back in balance and gets some protein in his system). But I’ll be watching all the more closely, to see how Phil Schiller takes on the challenge of igniting excitement in the Mac faithful. Like many product managers, I have picked up a few tips about presenting product over the years from Steve, and Phil will have his own style and his own techniques which I can hopefully also snarf.

Product predictions? I like John Gruber’s, and can lend credence to the iLife prediction because I finally got the most recent version as a Christmas present. Pretty sure there won’t be any new iPhone products announced today though (outside of the iPhone version of Delicious Library).

I’m pretty sure that Apple won’t be announcing the Mac Wheel today, though (hat tip to Chris Eng for the pointer):

Apple Introduces Revolutionary New Laptop With No Keyboard

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.

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.

Screenshots in software user documentation

I’ve been up to my eyeballs in user doc recently, our software-as-a-service product offering having matured to the point that novice users need some guidance to get started with the software. This being a startup, we don’t have a tech writer, and I’ve added the relevant hat to my normal product management job–and rediscovering my deep respect for the profession.

A tech writer has to know the software better than anyone else from the user’s perspective, and has to understand the compromises, incomplete implementations, and other hazards of software well enough to explain to the user how it’s supposed to work in a clear, intuitive way. Tech writing reminds me of Henry Miller’s description of proof-readers in Tropic of Capricorn, which I took many years ago as a motto while working on the production of the second or third issue of Rag & Bone:

The world can blow up — I’ll be here just the same to put in a comma or a semi-colon. I may even touch a little overtime, for with an event like that there’s bound to be a final extra. When the world blows up and the final edition has gone to press the proof-readers will quietly gather up all commas, semi-colons, hyphens, asterisks, brackets, parentheses, periods, exclamation marks, etc., and put them in a little box over the editorial chair. Comme ça tout est réglé…

…A good proof-reader has no ambitions, no pride, no spleen. A good proof-reader is a little like God Almighty, he’s in the world but not of it.

So tech writers are a little like proof-readers–the release may blow up, but the tech writer will still be there updating the user documentation and taking the latest screenshots.

Which brings me around to the question at hand: the tension between the need for screenshots in documentation and the definitive non-agileness of it all. A thread on the Joel on Software Discussion Group questions the need for screenshots entirely but comes around to the concept that, yes, you have to retake the screenshots every time you update the GUI, and yes, it’s a pain in the butt, but it’s part of the cost of doing business. I was hoping for some more practical guidance: is there a rule of thumb on what to illustrate with a screenshot and what to leave out?

A report on the usability testing for WordPress 2.7

Jane Wells at WordPress opens the kimono further on the decision to redesign the administrative user interface for 2.7. I griped a while back that it seemed like the design changes were being made in a non-systematic way, but it turns out there were solid usability testing exercises prior to the surveys we’ve all seen about structuring the navigation menu. She also includes a detailed usability report covering the eye tracking studies and the different stages of the process. Sounds like the new administrative screen is genuinely a usability improvement in terms of the metrics that matter (task success and time on task).

I also found it interesting that participants had a strong emotional connection to the 2.5 admin interface even when the formal usability metrics proved that they had trouble using it! Apparently good graphic design (my attraction to the UI) helps to mitigate formal usability flaws–a point worth remembering.

Test driving Google Reader

One of the downsides of being an early adopter in some areas is that I’m a late adopter in many others. I was using a desktop RSS aggregator back in 2002 (Radio Userland, then NetNewsWire) and so came late to the web-based news aggregator market. When I did hop on board, I used Bloglines, one of the early web based aggregators, and so missed out on Google Reader. I’ve stuck with Bloglines because it works and because it works well on the iPhone.

Yesterday, Bloglines wasn’t working. I haven’t seen anything posted about this, but while the site’s UI was up I didn’t get any new results for any of my 175 feeds from about 11 AM on. So in the early afternoon I decided to give Google Reader a spin.

One of the nice things about feed readers is that it’s pretty easy to take all your feeds to a new reader, thanks to OPML (one of Dave Winer’s many innovations in this area). Most feed readers support exporting your feed list to OPML, a structured XML format, and support importing feed lists from OPML. So you can pack up your feeds and easily bring them to a new place–minimizing vendor lock-in. I did that with my Bloglines feeds and was up and running quickly in Google Reader.

One thing that struck me almost immediately was the poorer UI in Google Reader. While it uses the same left pane navigation–right pane reading metaphor as Bloglines, the left pane is cluttered with a bunch of stuff on the top–starred items, trends, shared items and notes, a big help pane, and THEN your list of feeds. Bloglines’ feed list takes up the whole left pane and is just your content–much easier to manage–while other information like your personal blog and “clippings” are in separate tabs. If you’re just interested in reading feeds, Bloglines’ navigation is easier and less cluttered.

The right pane UI is a little better too, imho. I find the separate drop-shadowed feed boxes in the expanded view (what NetNewsWire used to call “smash view”) distracting; Bloglines’ zebrastriped list is visually flatter and doesn’t get in the way of the content. And I can’t imagine a use for the list view for most of my RSS feeds; though perhaps the notification-only ones are better suited for this kind of presentation, I can’t imagine trying to read BoingBoing or even Krugman this way.

Google Reader does feel a little snappier–feeds update more frequently and quicker. But the reading experience is actually slower, because items don’t get marked as read on display, but only if you scroll them off the screen. That might be beneficial for some people, but I’m a quick scanner and like to run through the feed list quickly. And because Google Reader doesn’t fetch all the items in a folder at once, dynamically fetching items as the user scrolls, there’s no way to quickly scroll to the bottom and read everything all at once. You have to wait for the fetch to catch up, then scroll to the bottom again.

So this morning I was pleased to see Bloglines is back online. I’ll still test out the Google Reader iPhone experience, because there are things that don’t quite work for me in Bloglines’s. But I’ll be continuing to use Bloglines in my browser.

Technical Debt part II: Security debt

I wrote previously about “technical debt,” the concept that the decision to defer necessary technical work (adopting an updated version of a new component, refactoring code to reduce cruft, etc.) accumulates across releases until it absorbs a project team’s entire capability to develop code. You “pay interest” on technical debt because it’s much harder and consumes many more resources to make a necessary technical change the further downstream you get from the point where the change becomes necessary.

It occured to me today that there’s a specific flavor of technical debt, security debt, that is both more insidious and much easier to see in operation, because we have so many prominent examples of it. It might not have cost the developers of Windows too much more to make the OS more secure at design time, but some of the decisions were deferred, until the point where you had whole features introduced to address security deficiencies in prior features, and the six month long security push that postponed Vista’s launch while the team took care of outstanding security issues in the already-shipped version of the OS.

What’s interesting about security debt to me is that it balloons over time. My once-favorite mix sharing site, Art of the Mix, is a good example. The guy who developed it didn’t really understand SQL injection or XSS, or at least didn’t code defensively against them, and it’s become a hive of malware as a result–and is now flagged as a “reported attack site” and blocked by Firefox 3. So, to carry the metaphor to its logical conclusion, the site’s security debt drove it into a kind of “bankruptcy” when it proved susceptible to drive-by SQL injection attacks.

So how do you avoid incurring security debt? Learning good development practices is a good start; keeping up on the prevalent attacks–the current risk space–is another. But there’s one key thing to remember about security debt: in many cases fixing the underlying flaw that permits exploitation is far far cheaper than getting hacked, or even putting bandaids like web application firewalls in place.