I am a software programmer. Not by choice, but by will. I like open source software as much as the next guy, but the problem of how to reliably fix bugs still has not been solved by open source.
Between Heartbleed and Shellshock, the "many eyes" theory put forth by Eric Raymond in The Cathedral and the Bazaar is fairly conclusively dead.
So what is a programmer to do?
How does one fix bugs that you write into your own software?
My mentor who taught me a vast amount of the architectural programming that I know now had a method that he used to debug his own code. It involved copious amounts of paper, which is why I don't use it more myself. He printed out his entire source on paper. Cut it to ribbons. Tossed the giant pile of source ribbons into the air and collected, sorted, and reassembled the code.
The success of this method relies on forcing entropy and chaos into your brain and forcing you to look at your code from another perspective. It breaks the "what you imagine, is what you see" paradigm in coding.
This works for debugging individual source files, but what about component and system-level bugs?
The best method that I have found so far for debugging system level bugs, is comprehensive component and system-level diagrams and application programming interfaces that define "how it should work." Then I have to pick through the entire system, call by call, and interface by interface, to find places where the component or system operation is inconsistent with my design bible.
It is, ironically, a lot like my philosophical life, where I have my design bible -- the Bible -- and I have to pick through my own life in order to find places where it is inconsistent with the "how it should work" principles laid out in the Bible.
It is curious... and kind of crazy. Everything really is connected in some manner.
