Release Easy Release Often

This was a FreudianTypo of ReleaseEarlyReleaseOften?, and it speaks volumes to me. Many software houses kill themselves to make the release deadline. Some of them practice iterative development (usually EvolutionaryDelivery), but it's still the same. People slack off at the beginning of a cycle and work overtime near the end.

So instead, take it easy. Deadlines are only in your mind. Just keep coding, keep releasing. Release as soon as the product restabilizes, which should take about half an hour. Then when a deadline arrives, give the latest release, and keep going as if nothing happened.

This will avoid BurnOut. It also encourages keeping the system bugfree at all times because managers will learn they can request binaries at any time as well. And that means quicker feedback too. This is good.

What I found effective was to constantly release. I didn't have a choice as I was working on a DotCom solutions start up. Potential investors and customers may want a demo at any time with the latest whizbang features. This isn't as bad as it sounds. Our solution was dead simple.

Create a task list, say in Excel. Anything not on the list doesn't exist. Requests to add features by the coffee machine definitely do not count, let alone meetings, or contracts. If you're anal about this, managers will conform because it's not a bad idea anyway. You ought to break the task list amongst three tabs: Active, Completed, Deferred. Only managers may move tasks to deferred, say during a descoping.

Then, since all those tasks need to be implemented ASAP (don't you love marketing?), the programmers get to choose what they want to work on. Don't worry. Management and marketing will emphasis greatly what really needs to happen first anyway. Only a suicidal programmer will ignore those requests. Once a programmer chooses a task, he puts his name in the appropriate column.

The programmer codes it up, tests it to death (or vice versa), and checks it in. Warning: Use a real versioning system like SourceSafe and unlike CVS, or else the multiple checkins will kill you.

If you have a QA department, they can just grab the latest binary and test it at any time. Ultimately, they control the release schedule, sure, but I'll tell you it feels good to be "shippable" at any moment. -- SunirShah

Tangential but potentially interesting discussion of UnreservedCheckouts moved there.

Also check out a continual integration/build tool named CruiseControl at http://cruisecontrol.sourceforge.net/ . The guys over at ThoughtWorks were nice enough to release this application that monitors your source control system and when a file is changed, automatically rebuilds your application and runs the tests. --AngusMezick

Similar to CruiseControl is AntHill but it offers a little more functionality and is easier to use (also open source)