A Day of Bugs: December 17, 2024 - 17/12/2024

Software bugs

Have you ever taken the time to count the number of software bugs you encounter in a single day? Today, I did exactly that: I kept a running list of every bug I ran into, both in my professional life as a software engineer and in the production software I interact with as a consumer. Spoiler alert: I encountered more than I expected.

A Day of Bugs: December 17, 2024:

Here’s the list I noted down:

• Home Wizard Smart Socket: It failed to turn off automatically based on its schedule.
• Google Home: It turned off only 4 out of 5 lamps grouped together in my home.
• Apple Podcasts (Car Integration): Connecting my iPhone to my car auto-played a random, already-finished podcast episode. This has been happening for months.
• Wi-Fi Dropout: My Wi-Fi connection dropped for 5 minutes. Restarting the router fixed it.
• Smart Backyard Lights: The app reported that the lights were online, yet they stubbornly stayed on.
• YouTube Ad Glitch: YouTube got stuck on an unskippable ad and refused to play the actual video, even when I clicked “skip.”
• npm update Fail: While writing this blog post, I ran npm update, which failed because it couldn’t remove a specific module.
• Outlook Meeting Room Policy: At work, our Outlook policy to prevent double-booking meeting rooms mysteriously broke.
• Sonos Beam Gen 2 Alarm: My 7 AM music alarm didn’t go off, despite being correctly configured.
• iPhone notification: Seemingly I couldn’t open my one of my notifications, the notification just became unresponsive.

10 Bugs —Not bad?

Ten bugs in a single day. Honestly, that doesn’t sound too catastrophic. Perhaps I didn’t notice others and just shrugged them off as “one of those things that happen”. But when I think about the sheer scale of the software I interact with—from smart devices and apps to corporate tools—this number feels low. This brings up an interesting question: How many bugs do we encounter in a day that we simply accept without even realizing it?

As users, we’ve become conditioned to tolerate small glitches, quirks, and workarounds. My Sonos alarm didn’t play? Oh well, I’ll just hit play manually. My Wi-Fi dropped? I’ll restart the router. We accept the fragility of software as part of our digital lives. But should we?

Accepting Imperfection in Software

Here’s the thing: most of the companies behind these products are massive, multi-million or billion-dollar organizations with resources that dwarf many industries. Should we excuse them for delivering buggy software? Would we hold a physical product, like a hammer, to the same standard?

Imagine buying a hammer whose handle falls off every now and then. Would you simply reattach it and continue using it? Probably not. You’d return it, demand a refund, or replace it with something reliable. Yet, when our smart devices glitch or our apps behave unpredictably, we rarely demand the same level of accountability.

Why?

Because software isn’t tangible. Its failures, while frustrating, are often minor. The consequences of most bugs I encountered today were relatively small—a skipped alarm, a failed npm update, a light staying on longer than it should. Software bugs often fall into the realm of inconvenience, not catastrophe.

As a Software Engineer: Am I the Problem?

This realization forces me to confront a question I often wrestle with as a software engineer:

Am I part of the problem?

I rarely deliver “perfect” software. Most of my work falls into the realm of “good enough.” And in many ways, that’s a result of the environment I work in—a world that prioritizes efficiency, speed, and iteration over perfection. “Ship it now, fix it later” is the industry mantra. Perfect software is expensive, time-consuming, and, frankly, unrealistic.

But at what cost?

When I, as a user, encounter these daily bugs, I wonder where the line is. Should we, as engineers, push harder for reliability and robustness, even if it means sacrificing speed? Should companies prioritize stability and polish over shipping the next big feature? Or is a certain level of imperfection acceptable in a world that moves this quickly?

A Social Contract of Software

Ultimately, there’s a social contract at play here, users tolerate imperfection because the value of software outweighs its shortcomings. A smart light that fails occasionally is still more useful than a traditional one. A podcast app with quirks is better than not having instant access to podcasts at all.

But that doesn’t absolve us… the engineers, companies, and the tech industry of our responsibility. As creators of these tools, we owe it to users to deliver software that’s not just “good enough” but reliable, trustworthy, and consistent. Perhaps the first step is acknowledging the problem. Counting the bugs we encounter, questioning their inevitability, and challenging the mindset that minor glitches are “just the way things are.” If we don’t, we risk normalizing mediocrity and letting software fail its users—little by little, bug by bug.

So, next time your smart alarm doesn’t go off or your router mysteriously fails, ask yourself:

“Am I okay with this?”

And if the answer is no, what can we do to change it?