«    »

Release When Ready

There are several strategies for producing software releases. One approach is to release by schedule – the software ships on a fixed date defined well in advance. Another method is to release based on budget – the work stops once the money available is exhausted. I believe, however, that the best strategy in general is to release when ready. I define ready as meaning that the code has been reviewed and unit tested by developers and the software as a whole exercised by separate testers with no serious (unacceptable) outstanding defects. Blizzard Entertainment, the software game company behind many gaming hits such as World of Warcraft, Starcraft, and Diablo, has publicly stated that they use the release when ready strategy: "our goal at Blizzard is to not release a game until it's ready." I believe this is one of the key reasons Blizzard has enjoyed consistent success with their games.

Why do I feel that the release when ready strategy is generally best? The objective behind creating software is to have it fulfill a function, and to do this it must work properly. My definition of ready software is essentially a more precise way of saying that the software works. If the software does not work properly, why would you release it prematurely? There are a variety of factors responsible for the large amounts of premature software being released:

  • Politics: A mandated budget or release date with no basis in reality or an arbitrary reduction in the schedule after it has been estimated are both problematic. In fact, such practices could be considered a fourth release 'strategy': release by management fiat. A more subtle case when politics has a negative impact is when it is onerous to change the budget or release date due to the bureaucracy and paperwork involved.
  • Fixed Resources: There are situations where the amount of time or budget is fixed and cannot be changed. One example is software changes due to new legislation that comes into effect at a certain date, such as the recent change in the start time of daylight saving time. Startups often have limited funds, and need to have a software release to market before that money is exhausted.
  • Competition: There is a commonly-held perception that being first-to-market is a competitive advantage, and this belief causes marketing departments to push for accelerated release schedules.
  • Demand for Features: For both commercial and enterprise software, consumers and users generally demand more features over quality. After people start using the software and discovering problems, then they might begin to demand higher quality. Even then, sometimes the users are not the purchasers, as is the case for most business and enterprises software. This demand for more features influences development teams to include just one more feature rather than spend the time necessary to ensure the software is ready for release (i.e. via code reviews and testing).
  • Ignorance: Managers who do not understand software development may come to believe that the software is ready to release when it really is not. This is a common risk of producing software prototypes.

These factors can make it difficult to impossible for a development team to apply the release when ready strategy. It is possible, however, to adapt to a release by schedule (or budget) strategy while maximizing the odds of the software being ready. To do this, you first must understand project schedules - in particular how the interrelated factors of time, resources, scope, and quality affect the schedule. Releasing software when ready implies that the quality is high, and a release by schedule strategy implies that the time is fixed. Adding resources is one option, but this is ineffective in the short term (due to Brook's law), difficult to accomplish quickly, and it does not help when the budget is fixed. This leaves scope as the single factor remaining. The key then is to carefully manage the scope throughout the entire development effort in a variety of ways:

  • Prioritize requirements and features into must-haves, important, and nice-to-haves. Work on the highest priority features first.
  • Structure and organize features into self-contained units to make it possible to drop features that cannot be finished by the release date.
  • Fully complete features before moving on to new features, especially as the release date draws near. This means that the work activities should not be structured by technologies or application layers, but by end-to-end functionality. For example, rather than working on the database persistence layer first for all the features, and then turning to the business logic and user interface, do all three layers for a single feature only.
  • Track the progress on each feature according to whether it is ready for release or not. This means that a feature is not done when the developer is done coding, but is only after it has been reviewed, tested, and all the serious defects eliminated. This implies that you do not wait till the end of the project to do all the code reviews and testing. Tracking progress by ready-to-release features allows you to still release working software if you run out of time by dropping all the incomplete features.
  • Define a project milestone sufficiently in advance of the release date for making the final decision as to what features will make the release, and which features will be dropped. This allows the time required to remove dropped features from the code base or disable them and to perform 'final' testing on the release candidate.

While the above points can help deal with a fixed release date, I feel it is far from the ideal situation. I believe the best approach is the release when ready strategy. You can still have a target release date, but make it flexible. You still aim for that release date using the points above for managing scope, but making the date flexible allows you to take a more rational and balanced approach. As the release date approaches, you can decide whether to cut features or push out the release date. During final testing, if too many defects are being found, you can decide to spend more time improving the quality of the software and push out the release date.

If you find this article helpful, please make a donation.

2 Comments on “Release When Ready”

  1. Mike says:

    Regardless of what the intent is, “release when ready” is usually what happens… just with a lot of unneeded stress in the middle.

  2. Great point. I just went through exactly that, and even worse, it was mostly self-imposed. After I adjusted my thinking to make my goal “release when ready”, instead of “release by date X”, my stress was greatly reduced.

«    »