The MySQL 5.1 release went out with a long list of bugs, according to the founder and original developer of MySQL Michael Widenius in his personal blog:

• We still have 20 known and tagged crashing and wrong result bugs in 5.1 35 more if we add the known crashing bugs from 5.0 that are likely to also be present in 5.1.
• We still have more than 180 serious bugs (P2) in 5.1. Some of these can be found here.
• We have more than 300 known and verified less critical bugs that are not going to be addressed soon. (The total reported number of bugs to the MySQL server is of course much larger)

In citing why the release ended up with quality problems, Widenius writes:

We have changed the release model so that instead of focusing on quality and features our release is now defined by timeliness and features. Quality is not regarded to be that important.

This can happen to the best of products and product development teams: in effort to meet market demand and capitalize on business cycles, quality is looked at as a “dial” that can be turned back in order to meet a specific deadline.

In response to how MySQL could improve its releases in the future, Widenius goes on to write:

There should also be, from MySQL management, an independent release criteria committee that would be the one deciding when the MySQL server is ready to be declared beta, RC and GA. This is something that Sun usually has for their other products.

Unfortunately, from personal experience, even having an independent release criteria committee can still allow a bad release to go out the door if timelines and features are prioritized well above quality.  The quality “dial” gets turned back as people in the committee feel the pressure from the priority of timeliness.

Having release criteria and an independent group responsible for certifying a release for GA is crucial to producing a good product, but setting quality as priority number one, ahead of timeliness and features, is also critically important.  Bottom line: as tempted as you might be to toss in another feature, don’t do it if your QA group tells you there won’t be enough time to cover it.

Filed under: Enterprise Web, Product Management