, 6 comments ,

"Just Ship It."

In my experience, most software-dependent startups fail because they never actually finish the software. It’s really that simple.

I’m trying to figure out how I feel about Jeff Atwood’s recent proclamation: “Version 1 Sucks, But Ship It Anyway.” As a connoisseur of Software Projects That Suck, I get Atwood’s point: you don’t really know what’s wrong with Version 1.0 until some real customers get to play with it and let you know what they think. I’ve often spent days or weeks perfecting a feature that nobody cared about! Why not save that time by getting feedback first?

Well, there can be a few reasons.

  1. You have a hard deadline for the finished version. The deadline was wired for a specific customer, or for an external event such as Y2K or a holiday.
  2. Delivering updates will be difficult or expensive, as when the product is embedded.
  3. It’s a component that someone else is depending on.
  4. The software is unusable or dangerous in its incomplete state.

Or sometimes, as is often the case with my projects, you weren’t even involved until after the customer was already frustrated with a number of iterations and you just cannot ask them to look at one more not-quite-done release.

So how bad is too bad?

To me, the breaking point is when the software’s quality isn’t good enough to waste the time of your intended users. Getting a “pre-1.0 beta” version out is good, especially if your users feel it’s justified by a low or free price. But no matter how cheap the software is, when you can’t accomplish basic tasks, that “public beta” cycle is frustrating for everyone.

When developing in-house software, I feel the same standard applies. If you can do the essential things the software was designed for, and the intended users are happy to get their hands on it, great. You can use this version as a functional preview, collect more “cards” or “user stories” or simply “defects,” and hasten the next release.

When that doesn’t apply

I say these things because most of my applications get deployed in a Web or office environment. Many of the objections to Atwood’s “ship it anyway” maxim come from programmers who lack the luxury of pain-free updates. To them, a bug fix means you have to burn new ROMs or issue a product recall.

It sounds like the contrary of an Agile situation, but it’s not really. You can still do iterative development, and you can still update the requirements and design as you go, but you have to change your conception of what constitutes a “release.” Perhaps your Version 1.0, and 1.1, and even 1.2 run on simulators or sample hardware, and what the end-user sees doesn’t come around until 2.0.

Finally

The answer to “should I ship a sucky Version 1.0?” like a lot of things, is “It depends.” But the more you’ve seeded your code with effective unit tests and the more you’ve implemented continuous improvement, the better your chances are for a non-sucky Version 1.1.

If Version 1 “sucks” because it’s interface is kind of unintuitive, do you hold up because interface is important? Or do you ship because that’s the best path to finding a better way? Tough call. Life is full of compromises. When have you intentionally shipped a release you weren’t happy with? How did that work out for you? And in what way did agile practice perhaps affect that decision point?