The dictionary defines archenemy as “the chief enemy” where enemy is defined as:
noun,plural
en·e·mies.
- a person who feels hatred for, fosters harmful designs against, or engages in antagonistic activities against another; an adversary or opponent.
- an armed foe; an opposing military force:
The army attacked the enemy at dawn.
And I mention this because the original states that “bugs will be your arch-enemy for life.”
Obviously, this is hyperbole but if your primary job as a programmer is to ship functioning code and bugs prevent said code from working or it results the program yielding unexpected behaviors then, yes, you will forever be fighting them.
Bugs Are Part of the Job
Before writing this article, I thought about the various different projects I’ve worked on during my career and how bugs have affected each of them (including ones I’ve introduced).
- Some of these projects include enterprise grade web applications with various data center used throughout the United States.
- Others are small utilities that have maybe a dozen users.
- And then there’s a variety of everything in between.
There’s no succinct way to talk about how bugs are introduced, grow, change, are squashed, and are reintroduced into a software system.
The original article has a pretty good statement:
So the truth is you should assume that everything has bugs. That’s why experienced devs never trust their code if it runs successfully on the first try. Even if the QA engineer reports a bug, assume that the bug ticket has a “bug” and check for everything.
And I really like the idea that “you should assume that everything has bugs.” That’s the bottom line, full stop.
I Choose Software Over Hardware Any Day
Software is a broad term to encompass all types of products we use:
- iOS apps
- Android Apps
- TV apps (regardless of the vendor)
- Web apps
- Extensions
- Plugins
- Utilities
- Operating systems
- Components
- And on and on it goes.
It’s amazing human beings can collaborate to produce such things (regardless of the environment) and that these things continue to work despite the high potential and likelihood for error that exists.
Sure, we can put in place all types of automated testing around the code, we can hire QA engineers to test all sorts of edge cases, and we can have entire support departments dedicated to handling user feedback, requests, bug reports, and so on.
And still they persist.
Rather see them as an enemy that has to be defeated, overcome, or reduced into nothing as if there are two sides two a war, I prefer to see them as just as part of the job.
Yes, they are frustrated, yes fixing one can lead to another, and yes sometimes an improper merge can end up bringing a previously squashed bug back into the codebase.
But it happens.
For what it’s worth, one of the things that I’ve told myself over the years is that I’d much rather be working on software rather than hardware because the former affords us, among many other things, the ability to ship fixes, patches, and updates in a far easier manner than a physical product.
