You Broke Me? Why We Release With Bugs

The world recently saw the passing of Ozzy Osbourne. Those of you who know me know that Ozzy was at the top of my list of metal performers. I’ll miss knowing that he could show up on another artist’s record or release a new album. That said, on his “first final album”, No More Tears, he released a single called Time After Time. The video is entertaining, and the song is well done, but the lyrics that stick with me in regard to software are “time after time, line after line, you broke me”. Much can be read into this, but with a software delivery lens, to me, it reminds us that software frequently disappoints.

I occasionally like to channel my inner Ben Simo; ok, I don’t like to, but it is far too frequently forced upon me. Only once did I have the pleasure of meeting Ben, and that was in passing at a TestBash in San Francisco. If you are not familiar with Ben, check out his stuff. He runs into the same bad software we do every day, maybe more, but he’s quite eloquent when he writes about it. Big nod to Ben!

I wear hearing aids. They are controlled, in part, by an app on my phone. I won’t name and shame, but this app is a horror show. It’s laggy. It crashes frequently. It can work, it just doesn’t always work. Who thought it was a good idea to release this? And worse, I’ve gotten several “bug fix” updates to the app, but the way I need to use it, it doesn’t behave any differently after the updates. Who thought it was a good idea to release that?

As many of you already know, I was laid off a few weeks ago. Here in the US, I’m eligible for unemployment compensation until I get a new gig. Because the government is going to government, I have to interact with two websites to deal with this stuff. Though both websites are owned/managed by my state, they were clearly developed by different teams. Additionally,  based on the site’s behavior, I suspect several teams worked on one of the sites. Why would you want to put your address on the same page as your ZIP code? Surely, no one would ever want to do that. Who thought it was a good idea to release this?

Just yesterday, I did something that “no user would do”. I had to create a new account on a site. When adding my birthday, I specified my correct birth month and correct birth day number, but I accidentally specified my birth year as 2025. The app then asked me to confirm that I am 0 years old. That’s kind of dumb in and of itself, but what was even more dumb is that there was only an “Okay” button. There was no “Cancel” button; there was no “No” button. I could not exit the screen’s pop-up. So, I exited the app to try again. 

But, in what state is my new account creation at this point? Is my account created? Will I get to re-enter my birthday? Do I need to create my account again? Does the system really think I’m 0 years old? There was no indication… but a user would never get their birthday wrong, right? Who thought it was a good idea to release this?

Regarding why “someone” decides to release a certain version of software at a certain, why indeed?

There are many reasons to release software “now” instead of “later”, despite what you or I might consider “glaring errors”. Surely, an app crash should garner a tester’s attention, but what if it only crashes on Paul’s specific device? Not “only on Device X that Paul happens to own”, I mean only on “Paul’s phone”, the phone with

• My set of other apps,
• My specific settings and permissions,
• My specific combination of software versions,
• My specific hearing aids, and
• My specific usage patterns.

What if I had opened the hearing aid app sooner? Or later? Would the crash still happen? Should this seeming corner case delay shipment? Those are bugs! They must be fixed! The app says, “You broke me!”

As I wrote previously, a major part of software testing is exposing and reporting risk. What do decision makers do with that risk information? The responsible ones at least listen to it and let those risks influence their decisions when it’s appropriate to. The ones who aren’t as responsible, or are perhaps less experienced, may ignore this info as “QA is just complaining” or “Nah, no customer will ever do that” (like mess up their birth date); eventually, that mindset will likely turn out poorly.

Here is how I hope leaders are thinking: if we release today, we’ll beat our competitor’s release by a day, but we are taking on some risks. As follow-ups: how does releasing today convert to revenue and add/retain customers in the face of those risks? What risks can our business tolerate to realize these business gains, and how is it mitigating or preparing to address the risks that are realized? The answer will be different for different organizations. Remember that, in general, the ultimate goal for businesses is to make money, not to make perfect software. Accounting for “Paul’s freaky phone configuration” is probably not economically feasible. The mindset is less “no user will ever do that” and more “not enough users will do that to negatively impact our business”.

Now, what about automation? When used in a context-appropriate manner, automation can help uncover risks sooner and provide faster time-to-feedback. How?

• Run sooner
• Check and report on the basic “are we egregiously broken?” paths
• Does anything seem “weird” regarding the code that was just deployed?
• Report as appropriate

Automation doesn’t have to be a pass or fail endeavor. Certainly, some of it can be, but all in all, it’s a force multiplier for delivery teams to uncover and report risks sooner rather than later. These risk reports help “them” make better informed decisions when “they” decide to release something.

Like this? Catch me at or book me for an upcoming event!