Little and often

The XP folks talk about the importance of making frequent small releases. This method has advantages over and above the obvious ones; not only do you get regular feedback from real users, you also get regular practice at doing a release...

Picture a project. You work like crazy for x months and then, right at the end, you take what you have and release it. But how do you release it. What needs to be done?

Doing 'a release' is considerably different from normal development work. The work required to take the product that's been produced and prepare it for prime time is quite different to the work that the team does whilst developing. If releases are infrequent then the team doesn't get much practice at doing a release. In between they forget how hard it is, there's never enough time allocated in the schedule for the work required to actually do the deed.

I don't know about you, but quite a lot of projects that I've seen have had fairly flaky release procedures. Releases never occur often enough for people to learn from the mistakes of the previous release. It's often just thrown together at the last minute. People code up until the deadline, or after it, and then, well, just kinda throw the results over the wall to the users...

It doesn't have to be this way.

A side effect of delivering functionality on a regular basis is that the whole process of 'doing a release' becomes something that occurs many times a year rather than just a couple of times a year. This is good. You get a chance to do the release often enough to remember what goes wrong and improve. If you have to have human intervention in the whole process then it's a bug. That bug in your release process should be logged like all others and fixed before the next release.

You should aim for a release that is easy. Building whatever makes up a release package from source should be automated. It's easy to fudge it if you're doing it once every 6 months. If you're releasing every 3 weeks you don't want to have to be involved in the packaging, you make sure it's automatic; you make sure it works... The aim is to go from a repeatable build to a release in one button press.

A good release is hard. Practice it. Release often.

Leave a comment

About this Entry

Sk8er boy was the previous entry in this blog.

The Joel Test is the next entry in this blog.

I usually write about C++ development on Windows platforms, but I often ramble on about other less technical stuff...

Find recent content on the main index or look in the archives to find all content.

I have other blogs...

Subscribe to feed The Server Framework - high performance server development
Subscribe to feed Lock Explorer - deadlock detection and multi-threaded performance tools
Subscribe to feed l'Hexapod - embedded electronics and robotics
Subscribe to feed MegèveSki - skiing