Bugs

Most bugs in our code have yet to be discovered.

They exist, either as mistakes, misunderstandings, typoos, or cheats. But the circumstances that would bring them into the light, as a pending development priority, have just not occurred yet.

There was a popular movement a while back that insisted that a limited form of testing would magically ensure that the code was bug-free. There was another less popular movement that doing a tonne of external work could prove the ideas behind the code were right. Both of these approaches are predicated on the idea that all bugs can be removed.

Pretty much the best and only reasonable definition of a ‘bug’ is that they are some annoying behavior of software that bugs someone. That is an incredibly wide definition that would include bugs for things like ugly or awkward interfaces, mismatches in conventions, inconsistencies, under-simplifications, and over-simplifications.

The healthy way to see bugs is that software is and will never be “perfect”. At best, if you work on it for a long time you might converge closer to perfection, but really you’ll never get there in your lifetime. So, bugs are an inevitable fact of building software. They exist, there are lots of them, and whenever you get a chance you should correct them, even if they are small or currently unnoticed.

The quality of any code is the number of bugs and the readability of the code itself. That is, it is the short-term usage, and the long-term extensibility, of the stuff you are building. The work to remove bugs is an exponential curve. It is easy to remove easy bugs, but it is a crazy amount of work to find and correct the difficult ones. Some bugs are just out of reach of the time frame. You may or may not know about them, but you’d never get the time to fix them either way.

Because bugs happen, any sort of release/deployment process needs to deal with them. That is, there is a strict, slow, correct way to release the next upgrade, and there is a fast, dirty, somewhat risky way to just get a patch into the wild. You have to have both, but the default is to always take the longer, safer way first.

There are lots of things coders can do to prevent and catch bugs. Usually, they are ‘habit’ driven. That is, without knowing any better, some of the ways people are constructing code is far more likely to be buggy. But if they just made small changes to the way they were working, fewer bugs would happen. As well, there are lots of ways beyond independent ‘tests’ that would help detect and prevent bugs from getting out into the wild. We have to accept bugs, but we can also change our working habits to reduce their frequency.