How big should a release be?

I've been pondering this one for a while and spurred into action by a recent (ish) post by Glenn Engstrand on 'The flow of product' I'm finally going to get some thoughts onto paper. The obvious answer is - 'it depends', which is true if a little tautological. The interesting question is 'What does it depend on?'.

  • Internal business pressures: Enterprise software has a schedule dictated by quarterly sales and revenue targets and this exerts a strong pressure on releases to be constrained to the same cycle. Deals closed this quarter need software shipped next quarter with inevitable enhancements made to satisfy the functional or operational requirements of the new customer.
  • bar chart

  • External pressures: Most businesses have an external timescale they have to be in tune with, for games companies Christmas has a big effect whilst educational software producers must fit into the rhythm of terms and years. .
  • Deployment risk: Consumer software can be hard to update, forcing releases to either be minor updates that an automated update process can manage or to be periodic major releases, say yearly, when customer intervention (and/or upgrade charges) is required. Web-based applications have a lot lower risk and they can afford smaller releases, ideally split tested before full adoption, safe in the knowledge that upgrading or reverting everyone can be done quickly and easily if a problem arises.


  • Collateral material - folders

  • Testing: One of the main 'per release' costs is that of testing. We all have our suites of automated unit tests but there are almost always additional manual tests that are required and the nature of the project often determines how expensive and exhaustive these must be. A web service should require little to no manual testing. A desktop or web-based application always requires some manual checks.
  • Collateral: Each new release needs a whole range of collateral tasks to be completed, documentation and training materials need writing and proofing, manuals and boxes need printing, CDs pressing, customer mail shots sending. For enterprise or consumer applications this list can be long enough to exert an upward pressure on the size of a release. For business applications designed and consumed in-house, the collateral cost can be minimal.

When I first started working with a company delivering web-based solutions after years of experience in the enterprise market, I found the change in release size and scope difficult to adjust to. I was used to releasing be an expensive process, requiring a lot of planning, not just of development time but also to ensure the schedule was aligned with those of the sales and marketing departments and in preparing and producing all the collateral material which works to its own material schedule. In that environment the choice of release schedule is between yearly, quarterly or monthly; for a web-app the choice is more likely to be between daily, weekly or monthly.

Additional tensions may arise when a single company or product suite has conflicting pressures on their release schedule yet the requirement for interoperability forces them to move in lockstep - a classic example being hardware devices and the accompanying firmware. Or, more relevantly for me today, Psonar, which consists of a desktop application working in concert with a rich web-app. A final and also topical consideration is that of the first release - which is a special case that requires a plan all of its own - polish to perfection versus release early and get the feedback rolling in.

and oh yes, I am experimenting ineptly with stock photos.

Did I mention again that Psonar are giving away an iPod Touch?

pre-register with psonar and win an ipod touch