Releasing Early and Often

Two months ago I had the pleasure of offering some advice to Mike Hofer. Mike has developed a library for .NET that makes it easier for developers to validate function arguments, something I am very much in favour of. The library is called NValidate and you can find out all about it at www.nvalidate.org

Back in September Mike was struggling to release his software. Why? Because he couldn’t stop himself adding functionality! This led him to post Feature Creep vs. Feature Completeness on Construx Conversations in which he asked whether the set of features he had coded so far was enough to justify a public release. I replied to say that NValidate already had more than enough functionality to justify a release and that releasing something sooner rather than later would provide other benefits as well…

Why release early?

I first read about the idea of releasing early and often in The Cathedral and the Bazaar by Eric S. Raymond. Eric explains how Linus Torvalds treated users as co-developers and he goes on to say that:

Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.

It goes without saying that you can’t treat your users as co-developers if you haven’t got any users. And you won’t have any users until you release.

Paul Graham echoes this sentiment in his excellent essay The Hardest Lessons for Startups to Learn. He cites a great example of how little functionality you need in an early release for it to be useful:

Wufoo released their form-builder before the underlying database. You couldn’t even drive the thing yet, but 83,000 people came to sit in the driver’s seat and hold the steering wheel. And Wufoo got valuable feedback from it.

Why release often?

Releasing early on it’s own is not enough. After your initial release you need to generate a stream of new features and bug fixes. This stream of visible improvements is what keeps your users interested and willing to help you develop your product. Eric S. Raymond puts it like this:

Linus was keeping his users constantly stimulated and rewarded – stimulated by the prospect of having an ego-satisfying piece of the action, rewarded by the sight of constant (even daily) improvement.

And Paul Graham also adds that regular releases have other benefits as well:

This is not just a good way to get development done; it is also a form of marketing. Users like you even better when you improve in response to their comments, because customers are used to companies ignoring them. If you’re the rare exception – a company that actually listens – you’ll generate fanatical loyalty. You won’t need to advertise, because your users will do it for you.

So if frequent releases are such a good idea why are IT companies and departments notorious for long release cycles?

Too much process

I think that Ed Gibbs has hit the nail on the head in his post Early Releases. The notion of any change costing more after requirements have been defined is highly ingrained in most IT organisations. Many companies actively resist change after a certain stage in the development life cycle and use overly bureaucratic change control processes (check out Ed’s example of a 44 page requirements document for a change that was already completed).

Does it have to be like this? Is releasing early and often the sole preserve of the open source community and Internet startups? Of course not! Agile methods are doing an excellent job of popularising the idea that software development does not have to consist of one single perfect release delivered in two years. But you don’t have to embrace an entire Agile methodology to take advantage of this idea.

I once led a team of developers who had two months to write and release a new software application. Half way through development my client phoned up and asked if he could visit us with some end-users and try it out. Many features were not ready yet and some of the code still had bugs but, after consulting with the developers, I agreed. I made sure that my client knew what to expect but told him we would welcome feedback on the progress so far.

The users spent an afternoon playing with the new application and were able to provide us with some really good feedback and highlight some issues that we had not yet detected. They were delighted to see the progress we’d made so far and it helped to reassure them that we were taking the product forwards in the right direction. However the biggest benefit to my team was the increase in their motivation. Getting positive feedback from end users made them far more passionate about what they were working on. This is something that I have seen happen time and time again: when it’s out there, being used and providing benefits, developers become inspired to raise their game and deliver truly great software.

Advertisements

No comments yet

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: