The case against Easy Progress

Sitting here on my couch trying to figure out which GameChanger feature to work on next. Bouncing around adding in a few simple menu items, a cancel button at one point during the scoring of a base-hit, maybe playing with some UI alternatives around undo-flow. But something feels wrong, and I know what it is. I'm avoiding working on some deep API-refactoring that I have to do for live scoring. But it's 10:00pm on a Saturday, and I spent the day out with the family unloading some old furniture, buying toys for the little-one, grocery and hardware-shopping. I just want some easy wins.

I remember sitting down with a junior PM at a former employer, and he was asking me what should go onto the upcoming iteration schedule. He suggested Important Feature A, Important Feature B, and then maybe some bugs. So far so good. Since, he continued, A & B were "big rocks", why not fill up the rest of our time with whatever the developers thought were quick wins?

I told him that was a terrible way to prioritize. Two big reasons why it doesn't work.

1. Developers are notoriously bad at knowing the difference between "easy" and "impossible." There's plenty of discussion of this problem already.

2. More interestingly, I don't ever believe you should prioritize something easy over something important. Rather, I said, put everything in our system in absolute order. Give us the next 5 bugs in terms of importance to our users, and your priorities. We'll figure out what we can do from that list.

Most of the time, people do this to see the illusion of rapid progress- and I'm guilty of exactly that. But it's just an illusion: would you really want fancier buttons, if some of them don't work?

Half the time the "easy wins" are of debatable merit in the first place. In fact, once you finish some of the "hard wins", some of those "easy wins" are likely unnecessary anyway. Too much changes in the lifecycle of software to justify wasting energy on anything non-essential.

My IM status right now is "direction over velocity," and I want to live that.

Iterative Product Development, and why I'm an Apple Fanboy

I've been illustrating my points about iterative development for a while by using the iPhone as an example.  The shpeel goes something like this:

When Jobs got up on stage and presented the much-anticipated iPhone in early 2007, there were almost an equal amount of grimacing head-shaking as there was gushing praise for the device.  The main crux of the argument centered around the featureset.  It wasn't 3G, in stead using already-antiquated Edge wireless.  It didn't have a physical keyboard.  No push mail.  No cut & paste functionality.  No replaceable battery.  No Flash.  No developer support.

But it sold a million devices on its debut weekend, and by November 2008 had become the #2 device in the smartphone market, second only to BlackBerry giant RIM.  Palm.  Microsoft.  Years in this industry.  Apple won.  Recent momentum seems to imply that it's going to stay that way (RIM's BlackBerry is not really unseatable as a dedicated corporate email appliance, no matter Apple's corporate strategy).

Why did it sell?  The featureset it DID have was impressive enough that a large part of the market bought it anyway.  The design was amazing.  The iPod features were, for that market, far above the competition.  The browser had a slow connection, but gave the most desktop-like feel ever seen on a phone.  The core interface design was so flawless that it felt like a new category of device.

Now, if Apple had simply left it like that, those "missing features" would eventually have allowed Microsoft and Palm and RIM to push them back out of the market.  But of course, Apple followed quickly with the 3G iPhone, with push mail, corporate features, more memory, and an application store.  Note that it was still missing cut&paste, Flash, removable battery, background processing, etc.

To return to iterative development, what I saw was a commitment to delivering the featureset that the market needs at the time that it needs it, and no more.  Version 1.0 had everything right that needed to be right, and skimped on everything else.  That's classic modern software design practice.  Deliver the next most important feature with high quality.  When I'm writing software, I try to do the same thing.

And finally, this has a lot to do with why I'm a fanboy.  I don't buy an iPhone for the featureset it has alone.  I bought one because I could see where the platform was going.  I trust that Apple will continue to develop that platform and give me an even better experience with every release, and give me a better platform as a developer with each release.  Until Apple stops delivering on that promise, in their desktop MacOS, or in their mobile MacOS, or in any of their software, I will continue to buy their products.  I will continue to develop for their platforms.