Whose job is it to find and fix app bugs?
Software bugs are inevitable. It’s simply not possible to test for all usage scenarios and all device/OS combos before an app release, and that often comes back to bite the developer in the butt if the bug happens to be major. Many apps drop from high ratings to very low ratings simply because an update introduced a bug so bad that it breaks the app for many users. Question is, whose job is it to find and fix bugs?
Lately I’ve grown very tired of bugs. I’ve been in contact with the developers of some of my favorite apps trying to fix various bugs, with the absolute worst being in Scanner Pro. A couple of versions ago the developer introduced a bug that seems to be localized to iOS 5.0.1, a bug that may or may not be fixed in the next version, after I sent them multiple different logs. It feels like I sometimes do nothing but create app logs and send them off, in the hope that it will help the developer fix bugs. I’m sick and tired of it.
To be more precise, I’m sick and tired of spending my time helping to fix bugs that weren’t there a few versions ago, in apps that I haven’t chosen to get involved in the making of. Beta testing new software is fun, as you’re getting something completely new out of the experience – but those times, you know what you’re going to. Updating an app in Google Play and then finding yourself having to submit logs to get the app back where it was yesterday, however? Not so much. If I’m going to help hunt down bugs and fix apps, I want it to be my choice.
A couple of days ago it happened again, as an update to Dropsync was released. The change log held promises of a new and improved system that would speed up the syncing process something ridiculous. Obviously I read this with great joy, installed it, and left it to its own devices. I quickly realized that the app was now looping, syncing for a few seconds, then being idle for a few seconds, then syncing again. Over and over and over. I turned off the new sync method, and it went back to actually working. Dropsync is one of my favorite apps, one that other apps (Foldersync) haven’t come close to, and the developer has been helpful in trying to fix a bug I’ve had with it. Still, I’m very busy these days, and I don’t have much spare time. I then sat there, staring at the button to email the developer, wondering if I should open Pandora’s box and point out this bug. The last thing I really wanted to do right then and there was to get caught up in some “let’s try this” loop, and simply unchecking the new sync method in the settings got me back the app I had before the update: slower, but working.
I didn’t submit a bug report.
Like I said, I’m tired of these situations. On the one hand, I appreciate the work the developer puts in to add more features and improve the app. The new feature in Dropsync sounds amazing, something that I could definitely use. Bugs are often very specific, too, and a lot of people (understandably, frankly) leave bad feedback on apps instead of trying to help fix them – which makes it that much more important for others to step up. On the other hand, I just don’t have the time to essentially beta test every single app I have on my device. I feel like I’m being forced to spend my time gathering logs and information for something I never agreed to beta test in the first place.
It’s really a no win situation. Android makes it impossible for a developer to test every scenario, meaning that the choice is between not adding more features and possibly having those features break something. A gamble that can leave you with users proclaiming their love for the new features, or users cursing you for breaking the app that worked so well five minutes ago. App development has become something everyone can do, which means smaller teams of people working on the software, and less resources. As long as something is provided for free, no one can really complain, but the moment you start charging for the software, the rules are different. You then have a product you’re selling, a product that needs to work. I don’t think I would ever charge for software personally, as I would want the freedom to tell people to piss off if they’re unhappy with it. No price, no commitment.
I think the Tasker developer and the AutoRemote developer has it right. Any new feature in Tasker or AutoRemote is first put into a beta build available in the respective app’s support forum, where any bug reports can also be submitted. People who then want to be part of developing the app further can then help by testing the new software and submit any issues directly. These issues will then be fixed by the time the app makes it to the Play Store, limiting the number of bugs that make it into the release version. Having a separate beta system also means that you always have the option to roll back to the release version, whereas that’s often impossible with apps that just get released.
Unfortunately, many developers treat release versions and beta versions as one and the same. That is especially the case on Android, where updating an app is frankly too easy. No review process, just upload the new version and hope for the best. That practice has to stop, and it has to stop now. If you change something so major in an app that it has the potential to cause serious issues, you make it a beta first – or, at the very least, use disclaimers and make sure there’s an easily accessible older version available somewhere The expectation that any user can be called upon to generate and submit logs and bug reports simply isn’t realistic. People are generally willing to help if they get something out of it, but this is one case where asking for forgiveness rather than permission might seriously backfire.
