In the latest release of iOS 8.3, Apple promised to fix bugs that users have experienced since the iOS 8 release in September, eight months ago. Unfortunately in this latest release, a bug fix doesn’t seem to be in the near future for the collective.
It’s become my understanding as a loyal Apple customer that with each big iOS update, a bug fix update is quickly released. You can withstand a certain issue for a few days, but eight months of dealing with Wi-Fi connectivity issues, photos mysteriously disappearing from albums, or even having your phone lie to you about low storage space is just too long to have to wait.
These bugs seem to have quietly slipped past the development / QA team and landed right in the hands of the customers, where they were discovered. As noted in the Apple Support Community, the thread for the iOS 8 set of bugs has more than 85,000 views and 3,000 responses.
Even if Apple’s QA team created a variety of instances to test certain issues users have been experiencing prior to the iOS 8.3 update, they would have realized these issues don’t rest with them. As Jason Cohen discusses in his book, The Best Kept Secrets of Peer Code Review, if QA cannot reproduce issues found by users then the issues then you have to have a developer look at the source code. One of the ways the organization could have eliminated this issue was with the help of tool based code review.
Apple isn’t the only organization who deals with issues like this. Every day organizations ship products or releases where bugs are not always detected. In order to minimize the amount of bugs being sent, having a peer code review process in place is your best bet.
Not only does finding bugs during the code review process make it less expensive to fix, it also helps catch other bugs that may have slipped through the QA process. Having a collaborative peer review process allows issues to be discovered much early in process. Having a peer review process in place will also make it easier for development teams down the road to work on the source code because it’s understandable and remains maintainable for years to come.
With a peer code review process not only are you having your team of developers work on the code, you are also including the entire team, beyond developers, to ensure the code is bug free. Mangers, designers, developers, and the QA team are part of the entire process from start to finish because bugs that make it to QA are expensive to fix but bugs that land in the hands of customers are even more expensive to fix. To avoid having a product release cost more than expected, establishing a collaborative peer review process makes it less expensive and more manageable for your team when time comes for new releases.
Bugs found in the development phase are 8-12X less expensive to fix than those found in the QA phase, but they are 30-100X less expensive than bugs that reach customers. Making bugs found by customers even more expensive to fix then if your development team had discovered it during their code review process.
Quick bug fixes aren’t always the answer. But having a code review process in place will ensure that fixes are not introducing another problem to the fixed release. Getting to the source, literally the source code, will be one thing your organization can do to ensure that defects do not make it past the QA team and into the hands of the customers.
If your organization has a peer code review process, we’d like to hear from you. What are you currently doing to ensure software quality?