Lately it seems that virtually all of the software we have on our desktops and mobile devices is easily updated. Back in the day, the prime argument for building web applications as opposed to full-on client applications was that web applications could be updated instantly; push an update to the server and all your web users get the new experience. This model is now applicable to desktop and mobile applications as well. These applications check servers for newer versions, alert you when there’s an update, download it, and even install the new update for you. Your iPhone or Windows Phone 7+ or Android device also knows when Apps have been updated, and you can download those updates easily and wirelessly.
The problem with this kind of easy patching target is that more and more, I hear developers and even management saying things like “oh, we’ll just patch it later.” I suppose that’s an OK argument for some environments. Web 2.0 startups (as well as Google and others) practically invented the concept of the “perpetual beta”. The perpetual beta is that in exchange for getting a product shipped earlier, the product ships in a beta state where patches and updates to the product can (and often do) happen on a daily basis.
The downside to this is that your user base becomes your testers. Certainly not in all cases, but in a scary number of instances you start seeing less and less up-front testing because the developers have gotten used to their users reporting bugs, they fix the bugs, they push a new update. What I don’t like about this is that we’re training users to expect faulty software and we’re training developers to expect users to be the first reporters of problems. These are both, in my opinion, inexcusable.
If you want to call your software a perpetual beta then fine, call it that. But don’t let your users replace your QA team. You should still be reasonably sure that your software is stable and solid, and you’re using this beta period to gather feedback. Feedback is not the same as a bug report. As more and more shops go through this cycle of build-vomit-patch, there is high risk for software and its associated user experience to be just plain awful.
Take, for instance, this photograph below. It is of a VoIP telephone in use by a very large, very well-known hotel chain. Take a look at the time displayed in the top of the photograph. The time, according to this phone, is 0:12am. What? Are you kidding me? How could something like this possibly have made it past a QA process? I realize that a simple bug like displaying the time wrong (it’s either 00:12 without am or pm or it’s 12:12am, basic clock display logic that we’ve been using for decades). As soon as I saw this on the phone, the first thing that came to my mind is the fact that these phones are easy to patch. Push a button, the phones are told of a patch, they self-reboot, download a new image, and the update is complete. This is not an excuse for lazy coding.
So, the point of this blog isn’t to complain that my phone had a bug in it. The point is to complain that I’ve been noticing a trend lately, a trend where the amount of testing done on an application is becoming inversely proportionate to the availability of a quick and easy patch deployment mechanism.
As the title of the blog post says, easy patching does not excuse lazy coding.