Just like a novel, a program is an intricate tapestry of actions and events that are interwoven with each other. When there is no unified vision behind the production it unravels. One of the symptoms of this are the endless trail of bugs.

To the outsider, bugs are just bugs--bad program behaviour, but to the programmer bugs come in many different flavors that greatly affect how resolvable they are. Consider some of the possibilities:

Minor Bug - a variable transposition, off-by-one error, misassignment, the list goes on and on. These are the simple bugs. You may have to prowl through 10,000 lines of code to find it, but once it's found the fix is just a few keystrokes.

Third Party Bug - most programs use libraries written by other people which contain bugs. Isolating a bug to a library and testing it's behaviour to verify a mistake can be real chore. Even when you have found it, you usually cannot correct it. The programmer has to create a workaround. This can be time-consuming. In some cases the functionality of the program may suffer irreparable damage.

Heisenbug - developers fear Heisenbugs, bugs which appear and disappear again, more than anything. When you cannot reliably reproduce a bug it can result in an unresolvable problem. Heisenbugs are often caused by low-level problems such as bad video card drivers and bugs in the underlying operating system.

Logic Lapse - often something that is "done" isn't really. For example, say that when a coder originally wrote a routine to avoid duplications they only did a linear search through a data structure that in reality required a complex hierarchical search and now duplicates are being reported as a "bug". The coder has to go back and complete their code for real. Maybe the reason the coder did not write the hierarchical search in the first place was that it was at or beyond their programming ability. Could take weeks to "fix" this one. In fact, the coder is not fixing anything; they have a logic lapse and now they are getting called to the carpet.

Design Flaw - if the original design for a process will not accommodate the complete range of functionality necessary for the program to operate correctly the developer could have a serious problem. To the user it may only appear minor, but under the hood the developer might have to rewrite extensive portions of the program to correct the problem--assuming that the correct design has now become clear, a big assumption. The rewrites could continue indefinitely. A typical example here is parsers. A lot of programmers who are self-taught run into problems when they need to write a parser. Inevitably the parser has serious design problems. Without academic training some programmers will never be able to write a correct parser no matter how many rewrites they do.

Deliberate Bug - a lot of programs suffer from deliberate bugs: the designed behaviour either conflicts with another designed behaviour or is self-contradictory or turns out to create an unintuitive situation for the user. This kind of problem plagues systems that have non-programmers participating in the design. The hands-off designer simply does not realize the full effect of what they are ordering to be done. It's like an automatic lighter for a car. Very convenient until it goes off at the gas station and blows the driver up. Oops, didn't think of that.