Granted, there might be performance/load reasons for updating code infrequently. But if that’s not an issue, my personal preference is to update code as soon as it’s tested and ready to go.

To me, something doesn’t feel “done” until it’s actually live on the site, and I like to have things done as soon as possible so I can move onto the next task. The fewer outstanding tasks to juggle in the brain, the better.

i guess it was a different beast, being that we were dealing with authenticated accounts and people’s money. then again, the Tech group didn’t bend to get non-secure stuff out. it actually made a lot of us get gray hair — too much pressure, ’cause if we missed the push, we’d be waiting at least two more weeks.

at foxsports.com, we pushed once every week or two, which killed me. if you’re building social software, i think it’s important for the the users to know that the software is dynamic and growing, like the community. if broken things stay broken for too long, and enhancements aren’t make quickly enough, i wonder why i should care about the system / community when it’s clear that the developers aren’t as passionate about it as they should be.

kareem

We used to push code live as soon as it was ready which was a good thing early on but as our code base and team grew we realized we weren’t embracing refactoring and our code base was stagnating because it always had to be in a highly “stable” state so projects could be moved live at any moment.

Moving to 2 week release cycles turned out to be the right balance of encouraging refactoring (which inevitably brings a system into a less stable state even with high test coverage) while at the same time keeping the amount of change per release at a very manageable level.

To me the bottom line is that the release frequency is highly dependant on the company and the domain. While an early phase Web startup should be pushing changes very often, an online web brokerage most certainly should not. Once a company has more than 2 developers it’s my opinion that priority driven time boxed release cycles work best which I’ve written about here:

Time boxed versus Feature boxed release cycles

and the discussion that ensued on the server-side is here:

http://www.theserverside.com/news/thread.tss?thread_id=38287

In response to your “annoucement system” Mike, over here releases get “theme songs” which echo throughout the office. I believe our invitation system was given Airwolf.

On the other hand, the application platform (and therefore the code base) is very “mature” (read: several million lines of code, much of it more than 5 years old), the client is very concerned with quality of releases, and we have developers working across three countries, for about a half-dozen companies, committing to the head development branch.

QA for platform releases is non-trivial. Rapid-response issues are often posted the next-day, but those are not where most work occurs. Our ideal incremental versioned release cycle was suppposed to be three weeks, last I heard. Reality is that the client dictates the schedule completely. What are ya gonna do? :)

Now for our other, smaller projects, say the stuff I lead, we operate without branches in the code, and rely on continuous-integration tools to help us enforce a policy of always being stable for a release, and we set milestones to meet the needs of the client.