Masterminds of Programming: Conversations with the Creators of Major Programming Languages

by Federico Biancuzzi

By introspection. I study the program for so long and poke at it more or less systematically for so long that I have sufficient understanding to provide an educated guess where the bug is. Testing is something else, and so is design to minimize errors. I intensely dislike debugging and will go a long way to avoid it. If I am the designer of a piece of software, I build it around interfaces and invariants so that it is hard to get seriously bad code to compile and run incorrectly. Then, I try hard to make it testable. Testing is the systematic search for errors. It is hard to systematically test badly structured systems, so I again recommend a clean structure of the code. Testing can be automated and is repeatable in a way that debugging is not. Having flocks of pigeons randomly peck at the screen to see if they can break a GUI-based application is no way to ensure quality systems. Advice? It is hard to give general advice because the best techniques often depend on what is feasible for a given system in a given development environment. However: identify key interfaces that can be systematically tested and write test scripts that exercise those. Automate as much as you can and run those automated tests often. And do keep regression tests and run them frequently. Make sure that every entry point into the system and every output can be systematically tested. Compose your system out of quality components: monolithic programs are unnecessarily hard to understand and test.

When one is writing a programming system (or a book, for that matter), one needs to keep the entire system paged in one’s mind. Interruptions break one’s chain of thought but if the interruption is short, one can usually page in the system after some code review. After an interruption of months or years, I frequently find myself referring to papers, books, or notes in which I have documented my algorithms to refresh my memory of what I previously coded. I guess what I am saying is that good comments and documentation are a great benefit to the original system designers as well as others who have to maintain the code for long periods of time. Brian maintained a log of major decisions we made as we designed the language. I found his log invaluable.

We invented a way of solving problems by simply making it the other guy’s problem. It’s called specialization of labor, and it’s as simple as that. That’s how the humans differ from chimpanzees: they never invented that.