Always be shipping - onward and upward

It's been said before (by smarter people than me), and it'll be said again. In any case, I feel like blogging about it today, and so it's the subject of this post -- Always Be Shipping.

When I say 'Always Be Shipping', I mean that code should always be moving forward. Code can be in a lot of stages.

At the lowest stage, it's just an idea in my mind.
'I think our app should provide some calculations for the user'.

Then, it might just be a "TODO:" with pseudo code in the real code.  Example,
// TODO:
// loop through item list here
//   for each item hook up to new api 
// return new amazing data

The pseudo code eventually becomes real compiled/interpreted functioning code that you can test on your development machine.
Woohoo - it works on my machine!

If it's working on your machine, you should start rolling the code out. Even in my hobby projects, I have a few levels of roll out. For Android apps, I have:

• I start with the Emulator.
• Then I have a test android device.
• Next, is my actual phone that I use on a day to day basis. 
• Then I can enable for some alpha testers. 
• Then I can slowly roll out to some percentage of users. 
• Then I can roll out to all users. 

If you find yourself stalling at any point of this process, you should figure out why, and then push forward.

If you have lots of ideas and you never get around to coding them up, then you need to get focused and implement one idea.  A functioning piece of code is better than lots of theoretical brainstorming ideas. Every great product had a 0.1 version. Go ahead and write the 0.1 version so you can start on the 0.2 version sooner. Otherwise, you will find yourself at 0 for a while.

If you have a functioning version of your code, but haven't released it to the world, you should ask yourself why. Are you afraid of bad client feedback?  Get a friend to try out the change and get their opinion.

Are you afraid of performance issues? That's good, but don't just sit and worry. Figure out a way to quickly turn off your change if needed. If things go awry, you can get back to a steady state easily. Even if things go bad, at least you have identified a real problem that needs to be fixed. The alternative is that you are optimizing for doomsday scenarios that never occur. In the future, you can use this mechanism (of quickly turning off a change) so you aren't stalled in the future.

For most software development these days, shipping code is something you should do early and often. This is true for other things. For example, when blogging, I try to tell myself -- Always be publishing. It's easy for me to write half a blog post, get tired, and leave it unpublished as a draft. It would be nice if all our code and blog posts were perfect before shipping/publishing, but then we'd never ship anything.

So - stop reading and start shipping.