One of the blogs that I enjoy following – much like most developers, designers, and techies – is the 37signals blog.

Generally speaking, it’s a great blog to read if you’re into following a company’s philosophy and process, but one of the guys – Nick – shared a great post the other day that struck a chord with me personally as it relates to shipping software especially in the WordPress economy:

Shipping beats perfection.
Be open. Share your work.
Anybody can fix anything.

– Khan Academy’s development mantras are stunningly simple and powerful.

Good stuff, right?

But how exactly does this apply to me (or even others) in the digital publishing space.

All About Shipping Software

One of the biggest things that you hear discussed in online circles it the ideas of shipping and everyone has their opinions on how this should be done.

  • Some are are all for shipping as fast as possible, then iterating
  • Some are trying to perfect as much as possible, and then shipping
  • Some find a balance between the two
  • …and then there are other cases, too

To be honest, I largely attribute Seth Godin with this whole obsession with “shipping” because people talk about shipping everything.

I’ve seen people talk about shipping blog posts, shipping videos, shipping tweets, shipping newsletters, shipping ships (okay, maybe not).

But seriously, shipping has become this umbrella term that replaces other terms that are more relevant such as “publishing” videos or “producing” videos, and so on.

But you know what? When it comes down to it, I don’t think it matters a much as long as you’re getting stuff done.

Which leads me to the next point.

Perfection Prevents Shipping

Straight up, one of the challenges that I’ve had my entire career is feeling that my code needs to be perfect (which, admittedly, is an arbitrary definition because perfection is some internal metric that I have for myself) before I can ship it.

But the truth is that the web affords the ability to ship something that looks good and that’s functional and that allows us to make quick (read: weekly, daily, hourly!) iterations to improve the core product without causing full disruption and this is especially true as it relates to WordPress.

So one of the things that I’ve been challenging myself with along with some of the members of the development team at 8BIT is that if the project works, has a reasonable level of code quality (which is a balance between readability, testability, stability, and functionality), then it’s time to ship.

Perfection isn’t even attainable – why is that our goal?

There is always room to iterate and improve the codebase that’s running behind the scenes while the users are none the wiser. For designers, this is a different case.

Regardless, next time you feel that thing rise up inside of you – that fear or caution – that says your code isn’t good enough to ship despite the the fact that all lights are green, then go for it.

You can improve later.

At least, this is what I’m telling myself and my team.