It can be tempting, when programming, to disregard errors and the code paths that lead to them. Our programs can fail, and this can be painful to contemplate. Designing systems as if they will never fail might come from a hopeful, optimistic perspective. Nonetheless, reliable software won't arise from optimism alone. Experience shows that, given enough time, "whatever can fail, will".

At the beginning of a project, before even a single line of code is written, there is an idea about what will be built. This is "the specification" -- a description of something that doesn't exist yet, but should. It is the project's first bug report. With a specification in hand we can see that there is something in the world in need of fixing. Some aspect of the world is in an "error state".

Error is the ground state of all systems. It is effectively the lowest energy state of the system with regard to programmer effort. By applying effort (writing code, etc.), we can "lift" the system into a higher energy state.

A related concept is bit rot. Somewhat mysteriously, a program, unmodified, will eventually become unusable, falling victim to some unseen form of rot. Software systems are physical systems, and like all physical systems, are subject to the laws of thermodynamics. Without injections of energy (development) over time, software systems will eventually degrade into lower and lower energy states, until they reach the ground state -- the state where the system is in error.

It follows then that all software development is bug fixing. By organizing our development effort around identifying and resolving errors we can save time and resources. And by gaining familiarity with errors we can design systems and practices that not just handle, but uncover and even prevent errors.