I asked this question an year ago in StackOverflow and never got a good answer. Since Programmers seems to be a better place to ask it, I'll give it a try...

What is the better way to work with release management? More specifically what would be the best way to release packages?

For example, assuming that you have a relatively stable system, a good quality assurance process (QA), etc. How do you prefer to release new versions?

Let's assume that we are talking about a mid to large "centralized" web system (no clients), in-house development. This system can be considered "vital" for a corporate operations.

I have a tendency to prefer to do this by releasing packets at regular intervals, not greater than 1 to 3 months. During this period, I will include into the package,fixes and improvements and make the implementation in production environment only once.

But I've seen some people who prefer to place small changes in production, but with a greater frequency.

The claim of these people is that by doing so, it is easier to identify bugs that have gone through the process of QA: in a package with 10 changes and another with only 1, it is much easier to know what caused the problem in the package with just one change...

What is the opinion came from you?

  • ITIL describes approaches to handle releases and changes and everything in between. It is not a process, it is a set of guidelines.
    – Chris
    Feb 17, 2011 at 13:48
  • ITIL is similar to CMMI in that respect, and for some reason has a lot more marketing in America these days. It's a British standard designed less for software engineering and more for systems engineering (there is a difference). CMMI is an American standard that is more software engineering and less for systems engineering. IMO blanket recommendations of either are highly suspect. I.e. learn the lessons that need to be learned, but ignore everything else. Feb 17, 2011 at 14:52

1 Answer 1


In my experience there is a balance between providing regular updates to users and making the application high quality. So first, let's look at the extremes:

Releasing too often: When you release too often, the QA team is always behind the eight ball. Even though they may be creating/running automated test scripts, they need time to get that work done. When a large enough portion of the testing has to be manual, there will always be bugs that slip through. Short story--the probability that a high profile bug getting through to the customer goes way up.

Not releasing often enough: Two problems happen at this point--customers get fed up with the tool, and everyone gets lazy. When you have a long time between releases, developers want to do more, testers get less vigilant, and the chance of schedule slips go up. This is all due to the perceived extra time that everyone has. Customers who get impatient start calling for a new solution--one that will solve their problems today and not 6 months from now.

Finding the balance: There is a point where your team's productivity reaches a peak sustainable rate. You'll have to experiment to find what that is. IMO, 1 month is not enough time to implement any substantial feature and ensure it is working properly. My team works very well in 2-3 month intervals, although it is at peak efficiency with 3 months. You have enough time to do redesigns when necessary, and implement major new features. The test team doesn't feel like they have the luxury of time, but have enough to keep up and remain vigilant. Customers also can deal with 3 month release cycles--particularly if the quality of the release is high.

Finding the peak for your team will require measuring quality in some meaningful way. The only meaningful metric that really matters is:

How many bugs were found by your customers?

I don't care how many bugs were found and resolved in house, that's just a sign that everyone is doing their job. The more the better. I care most about how many bugs, and the severity of the bugs that the users discover. That is the most reliable direct measure of your software release quality I know of.

A related metric that is equally telling, but in a different way is:

How many new feature requests from the customers?

Feature requests are an indication that people really are using the system, and are thinking about how to make their jobs easier. The requests can be as simple as changing "happy" to "glad" in the help files, or as complicated as new ways to visualize data. It's important to distinguish a request for a new feature from a poorly designed user interface (that would be a bug found by the user). The number of feature requests is not necessarily an indication of missing the mark, it is more an indication of user interest. Also know that your customers are learning how the tool improves their jobs at the same rate you are learning about your customers. The customer can only visualize and recommend incremental improvements. It's up to you to determine if there is an underlying theme to the requests and find if there is a different approach that may address all the concerns.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.