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.

Rich Dad Programming, or: Technology Asset Building

Throwing away working code is a programming sin.  Slow?  Tune it.  Cluttered?  Refactor it.  Obtuse?  Document it.  The underlying philosophy is that even for a minimally complex application, there is a tremendous amount of business knowledge embedded in every innocuous line, along with the man-years of testing that went into ensuring its current performance, reliability, and general correctness.  Technology can be slowly polished, but that business logic is pure gold.

So my team at Conductor is gearing up to rewrite 3 different apps over the next few months.  We are in a place where little of our existing code-base is reliable enough to build around, leaving us little choice.

I'm not going to get into what went wrong to get us here, but I am convinced that managing our technological balance sheet will get us out.  The realization came to me when I was contemplating Higher One, a company I left 5 years ago, at which the majority of the code I wrote is still running, largely unmodified, in the core of a large financial system.  Somehow, what I did back then as a young engineer has survived and produced consistent returns.  We spent our time there developing Technologies that solved specific business problems, one after another, and those solutions survive still.

Specifically, I realized that our teams here need to start building "tech assets," which have long-term returns, and to minimize ongoing debt.  I want to build technological wealth.

So I'm taking this very literally.  We just had a planning meeting where we laid out 6 months of a product redesign, and I took the featureset and mapped that to a set of Assets to build.  The Assets are the technological blocks that will be the underpinning of the new product.  Big hairy "modules" like SalesForce integration, Authentication, an Ad Trafficking state machine, Activity Auditing, User Management & Permissions, etc.  In our UI code, which is a clientside JavaScript app, we're building out JSON-handling frameworks, message dispatching, and rendering layers.  The goal of each of these Asset projects is to build a unit of functionality, wrap it in iron-clad unit tests, and build a mini-prototype demonstrating the functionality.

2 months into the project, we'll start working on Features.  By that time, we should just be plugging things in and bickering over button corner style.  And next time, even if we shift direction rapidly or redesign the UI (like we are now), we should be able to repurpose our core Assets for new features and related products.  Effectively, having a stable of reliable assets reduces the actual cost of all future development.  That's how I define ROI in software development.  Assets yield technological wealth and, hopefully, cold hard cash returns, too.