I find reading app release notes a fun pastime. For whatever reason people who write these release notes in the App Store have no imagination, or a perverse sense of humor, or they have resorted to smoking funny cigarettes.
So many release notes include the phrases, in some version: "Bug fixes," "More bug fixes" or my all time favorite "Minor bug fixes and performance enhancements". Apparently their codebase is so bad that the bugs are multiplying faster than they can be fixed!
Take for example this major airline app I picked at random. Two stars. The current version and its predecessors:
- Bug fixes.
- Many, many, many bug fixes.
- Of course we are squishing bugs with every update.
- More bugs eliminated.
- Back end enhancements and smashing bugs.
- Minor bug fixes and tweaks.
- And as always, bugs have been squashed.
- And of course, the usual bug fixes with every release.
- Various bug fixes and backend updates.
- And of course, more bug fixes.
- Bug fix-a-thon.
- Bug fixes.
- Various bug fixes and back-end fixes.
- Squashed lots of bugs.
- Various bug fixes and continuous improvements.
- Several bug fixes.
- Various bug fixes.
Then a miracle occurs—there was a release nearly two years ago with no bug fixes!
Where the heck did all these bugs come from? When my mom was a child in Germany during the war, the local authorities demanded children in schools go once a week to the fields and look for potato bugs the Americans were dropping in the fields. Of course they never found any. Maybe the bugs are being dropped by a rival airline!
I have no idea how this airline builds apps or who builds them, and maybe the review writer just likes to rebel and comment on how miserable releasing apps is there. I know at my employer every release is a nightmare of bugs that can't be finished and are pushed to the next release (and then pushed again so they never die). Then defects are found after release, resulting in rounds of hot fixes which leak into the next release causing more defects and more defects to be kicked down the road.
Maybe I should be resigned that all software is riddled with bugs and quality is a thing that doesn't matter any more. Maybe I am too old and remember shipping code on floppies in boxes to strangers to whom we could not send a hot fix since we often had no idea who they were, so what we put on that floppy (or in Deltagraph's case, 10 floppies) had to live unpatched for at least 6 months. Perhaps as a dinosaur I am out of touch with modern software development and should just accept that each release should consist of 99% bug fixes and 1% new functionality, plus another 20% bugs to sow the next release's crop.
Yet I refuse to accept bugs, I didn't back then and I still can't today. I want the code I write to work according to my long standing philosophy: the code always does what it is supposed to do, never does what it is not supposed to, and is never surprising in what it does. I am not satisfied unless what I write functions.
Just because the customer expects things to work, since they are paying for this (directly if it's a product, indirectly if the software is adjunct to the real product like an airline or here), I want to make sure they get something that works.
I'd rather not have any bugs to fix and be able to take the time to build some useful, delightful, or necessary feature.
Someday I would like to read an app release note and see: "We didn't fix any bugs because we could no longer find any."
But I am just a fossil, don't listen to me.