Sometimes I worry about the level of completion that I’m willing to take before shipping.

On one hand, clients tell me that they love the sense of taste and little details that I bring to a project, but on the other hand I’m always convinced that I’m shipping too early.  That’s not just programmer paranoia either.  We’ve lost clients before by sending a beta that didn’t measure up.  I’m not proud of that, but it’s led us to better ways of testing and of communicating, so I’m not torn up about it either.

Once, six or seven years ago, I had a customer berate me for shipping beta quality software.  It was on the release of a 2.0, and I had a 2.0.1 out the next day for him, but I still feel disappointed in myself for letting that get by me.  Every other email I got on that release raved about the new features, but the one I really remember was the humiliating one.

Developers are great at ensuring code quality, but often we fall down on product quality.  Beta groups, integration testing, PM feedback, all that can only get you so far.  Eventually someone tries something you didn’t see, and now you’ve lost a customer.

I’m sure if I got a better business person in here, we’d talk about the cost tradeoff of quality control vs. keeping a customer.  But that doesn’t sit well with me.  I want to make amazing software, and too often I have to settle on good enough.

How do you measure that software is complete?  I feel like we need a role in the organization that’s just ‘software critic’.  Someone who doesn’t give a damn about what tradeoffs had to be made and where the budget was set.  If we can frustrate that person, then maybe it’s ready to ship.

How do you measure that software is complete?