These days, especially in the world of web-based applications the trend seems to be to release a product first and incrementally fix bugs. Many such applications are free (follow the freemium model) and the early end-users (or early adopters) are often the free beta testers (or guinea pigs). In the race to launch a software product companies are often faced with the dilemma of where to make compromises. This decision becomes that much harder when not meeting a deadline could be the "kiss of death." This means that very often developers gravitate towards meeting the deadline but knowing fully well that the software being released has bugs buried in it.
The reality is that in the web-based application (SAAS) business fixing bugs and updating the software is relatively trivial in comparison to shrink-wrapped software. As a result in many cases even before the end user gets down to accessing the system several bugs could be fixed!
We have an interesting anecdote in this regard to narrate. A customer required a specific set of features to be developed. After discussions it was agreed hat the effort will take us about two months. However, for various reason we started to slip on the target dates. We reached a point where it was becoming apparent to us that we could deliver but with some known bugs. The reality is that it could take a while before the customer and or their end-users would identify the bugs. So the question was, should we release or ask for more time despite knowing that this project was time-sensitive to the customer? We believed that "discretion is the better part of valor" and so we were preparing to prep the customer about the exact situation and sharing the known bugs well in advance of the deadline.
Thankfully, the customer came back and asked us to postpone the release (because of delays at their end) and we survived with time to spare. The product was released within the newly set deadline and the customer was happy as ever. Clearly lady luck was smiling on us in this case!
But it might not be true every single time. So that brings us back to where we started - the tradeoff between time and quality. If you are scratching your head, don't worry, its a topic of research.
Check out Sell First, Fix Later: Impact of Patching on Software Quality http://repository.cmu.edu/cgi/viewcontent.cgi?article=1028&context=heinzworks