It’s obviously a good thing for bugs to be fixed. Software should function correctly and without exposing the user to security issues, and updates to fixes for this reason are essential.
Unfortunately this sometimes, one might say often, has a negative impact on the user. The user may know of the bug and have a workaround for it, and fixing the bug may cause the cause issues with the workaround.
Embed from Getty ImagesNot to mention the fact that fixing one bug may result in the appearance of another or bring its existence to the notice of the user. No software can ever be considered to be completely bug free, in spite of the advanced tools which are available to test software.
When I was learning to program, back in the time of the dinosaurs, we were told to give our program and the specs to one of our fellow students to test. We called it “Idiot Testing”. The results were mind blowing. A tester would make assumptions, put in data that they consider valid, but which you, as the program writer had not considered, or maybe you considered it “obvious” that putting in certain types or values of data would not work.
Embed from Getty ImagesAlmost every time the tester would break the program somehow, which was the whole point, really. So we’d fix up our programs and give them up to be tested again. And the testers would break them again.
We were taught and quickly learned the advantage of sanitising the inputs to our programs. This meant we had to take the data as input by the tester and incorporate in our programs routines to try to ensure that the data didn’t break the program.
Embed from Getty ImagesSo we’d write our routines to validate the data, and we’d return an error message to the tester. We’d think that we were providing clear reasons in the messages to the tester, but the messages could still confuse the testers.
For example if the message said “The input must be between -1 and 1”, the tester might try putting in “A” or “1/4”. This usually happened when the purpose of the program was not clearly defined and described, not because of any denseness or sheer caprice on the part of the tester.
Then we’d update the programs again, taking into account what we had learned from the tester’s responses, and hopefully there would be more success with the updated program.
Embed from Getty ImagesThis seems to be more of an issue in mobile software, I believe, as many programs out there are written by a single person working alone, and I know that by the time I finish a program I’m heartily sick of it, and I write programs for myself as intended user. A person may upload a mobile app, with plenty of obvious bugs, and may never update it. It becomes abandonware, which may lead a general disillusion with mobile software as being buggy and never fixed.
When a developer does start to work on his program, and starts to fix the bugs, this takes time and effort. Meanwhile users may keep reporting issues with the published version. The developer has a dilemma. Does he/she drop his work on a particular bug to identify and fix the possible new bug? Or does he/she finish working on the current bug and eventually release a new version which would still contain the old bug?
Embed from Getty ImagesOnce the programmer starts on a new release, adding new features and improvements over the original version, bug notification and fixing acquires a new layer of complexity, one which a single developer may find impossible to handle, so he or she might abandon the software rather than take on the complexities of bug management.
Other times teams form or businesses take up the software, and bug management and fixing become formalised, but updates still need to be supplied to the users. From the user perspective, updates are more regular and fixes may be supplied in the updates if they are lucky.
Embed from Getty ImagesUpdates have had a bad reputation in the past. In the early days of computing operating systems (such as Windows) could become unbootable after an upgrade if the user was unlucky. This generally could be tracked down to issues in the driver software that controlled the various attached or builtin devices on the computer.
Things are now a lot better. Drivers are written to be more robust with respect to operating systems upgrades, and operating systems have become better at handling issues with hardware drivers. It is rare these days for an upgrade to render a system completely unbootable, though an upgrade can still cause issues occasionally.
Embed from Getty ImagesUsers have become used to preforming upgrades to systems and software, and in some cases they, by default, do not have a choice whether or not to upgrade. They do not, in most cases, know exactly what upgrades have gone on to their computers and do not known what fixes are included in these upgrades.
Software updates are often seen by users as a necessary evil. There are reasons for updates though as they may well close security loopholes in software, or they may enhance the functionality of software. Just don’t expect an early fix for that annoying bug though, as the developers will almost certainly have different priorities to you. If it isn’t in this update, maybe it wasn’t serious enough to make it. Hopefully it will be in the next update, which will be along soon!
Embed from Getty Images
Me on the net 