Trying to read our DNA is like trying to understand software code - with only 90% of the code riddled with errors. It's very difficult in that case to understand and predict what that software code is going to do.
Another effective [debugging] technique is to explain your code to someone else. This will often cause you to explain the bug to yourself. Sometimes it takes no more than a few sentences, followed by an embarrassed "Never mind, I see what's wrong. Sorry to bother you." This works remarkably well; you can even use non-programmers as listeners. One university computer center kept a teddy bear near the help desk. Students with mysterious bugs were required to explain them to the bear before they could speak to a human counselor.
System debugging has always been a graveyard-shift occupation, like astronomy.
I don't do bugs.
There's no such thing as a simple cache bug.
It's probably fair to say that the ratio of time our Connector developers spend in the debugger versus the Emacs buffer is higher than with most software.
The reality of most software development is that the consequences of failure are simply nonexistent.
Indeed, the woes of Software Engineering are not due to lack of tools, or proper management, but largely due to lack of sufficient technical competence.
The challenge with Postfix, or with any piece of software, is to update software without introducing problems.
The most effective debugging tool is still careful thought, coupled with judiciously placed print statements.
Simply put, when you have very large pieces of software, most of the tools look at the individual lines of code as text. It is often extremely powerful to look not at individual pieces of code but at a system as a whole.
Most of the effort in the software business goes into the maintenance of code that already exists.
The process of debugging, going an correcting the program and then looking at the behavior, and then correcting it again, and finally iteratively getting it to a working program, is in fact, very close to learning about learning.
Much to the surprise of the builders of the first digital computers, programs written for them usually did not work.
