Developers take pride in their work. We want to ship beautiful software using the latest frameworks, with a full suite of unit tests, that performs well and is über scalable.
But if we do that we’re probably not going to get anything out of the door, as it’ll never be perfect. The secret is not to worry about making something flawless.
I think Matt Mullenweg describes this concept best.
If you’re not embarrassed when you ship your first version you waited too long.
Just ship it!
Get version 1.0 out there as quick as possible, you really don’t know exactly what your potential users are expecting until they tell you. They are far more likely to tell you about a feature they really want, rather than tell you how awesome a feature you already have is. Releasing early and often gets you quick feedback from your users as you’re shaping your application.
Having direct feedback at this stage of the process is crucial as it will not only help you develop a better product but also you avoid features no one really wants. This quick development cycles will help you produce a sleek streamlined application that hopefully has a dedicated user base.
Having a user base that actually uses your application is important as Jeff Atwood points out.
It’s true. One key measure of success for any programmer is how much code you’ve shipped. But merely shipping is not enough. A more meaningful measure of success is to ask yourself how much code you’ve shipped to living, breathing, real-world users.
If your application doesn’t take off and users don’t get on board then it doesn’t matter as much with an early version. You’re much less invested and you’ll find it’s easier to jump onto something new.
How do I decide what goes in version 1.0?
You want something small which still delivers value. I actually take a piece of advice that Microsoft gives for designing Windows Store Apps which really helps you focus on what’s important.
What’s your app great at? Take a step back and look at your list of ideas to see if a particular scenario really jumps out at you. Challenge yourself to trim down the list to just a single scenario that you want to focus on. In the process, you might cross off many good ideas, but saying “no” to them is crucial to making a single scenario great.
For this blog I wanted something light-weight where I could easily write and post blog entries. When deciding what the first version would look like my vision statement was: >My blog will be great at creating and displaying blog posts.
There is no pagination between posts, no footer, there was no RSS, no comments, no tags, no archive, and it doesn’t render on mobile devices very well. In fact it’s missing many things that make a blog a blog, but that doesn’t matter.
1. I built and shipped this software in under a week
2. I can quickly create posts in markdown and they come out great
3. I added an RSS feed yesterday
4. I’ll be doing another release tonight
On top of that, because my site was up, I’m two blog posts and a couple of readers ahead.
Keep calm, ship early, ship often
By shipping early and often you can prioritise work that really matters to your users. It doesn’t matter if version 1.0 was mediocre, you’re optimising for the long term. With each release you’ll get a little bit closer to that nirvana of beautiful software that your users love and you’re proud of.