I am reminded of a quote from Peter F. Druker, a renowned management consultant who was, several years back, reputed to have said on one of those news shows (Sunday morning's Meet-the-Press or similar):

Never confuse motion with progress.

As a senior (maybe that should be senile? ;-) ) Systems Engineers, I keep a little notebook of the various Axioms of Systems Engineering that I have heard or read over my 30 years in the business. These guide much of my everyday thinking about all aspects of systems engineering. The above quote from Peter Drucker is one of those Axioms.

I was, not too long ago, asked to be the lead of an independent review team of 'greybeards' for a floundering satellite flight software effort. The flight software was woefully behind and had reached a point where it was the 'long pole in the tend' holding up the satellite launch (at a cost of about $75,000 pre day for the delay).

The project had an independent test & evaluation team (which has proven, over the years in my business, to be a most useful strategy).

That test & eval team, briefing the progress and their assessment of the effort stated with great pride that were finding and getting fixed...on average...about 20 to 50 bugs per day. And they had proudly sustained that rate for almost 3 months...and that the software development team could turn most of the 'fixes' on average in 2 days and, in many instances, were releasing new versions within a day.

My reaction was one of horror...but all of the senior managers were nodding with clearly impressed feelings, that this was wondeful! After all, that clearly would get the problems cleared up in no time.

My horror was the realization of how bad the underlying code was, how undiciplined and chaotic the development process had become, and how painfully incompetent it made the software development team look.

Several other fine and wondeful monks have made great observations about the reported situation of the OP. I concur with virtually all of them. I am especially sensitive to and agree with the comments that emphasize the sense that such a change rate seems to be symptomatic of an undeciplined process, of the implication that such a high rate of turnarounds might be indications of seriously flawed underlying software.

I really like this thread and everyone's comments.