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
