This story is an edited version of a message I recently posted on the Multics forum on LinkedIn.
Having your changes “go live” very quickly can be a powerful incentive. This is the story about the first bug that I introduced into Multics, which was a major operating system that was being created at MIT in the late 1960s and early 1970s.
I was a young MIT freshman who had been accepted into the Multics project. I volunteered to add a feature to the dprint (“daemon print”) command that queued requests for the line printer daemon to process. One of the managers asked me to record the number of copies in the request, instead of adding N requests to the queue. This change would solve a race condition involving the deletion of completed print requests. I made the changes and tested them to my satisfaction.
My changes were soon installed and I was thrilled to be allowed to improve the system. But my thrill was short lived, as I soon answered my office telephone and found myself listening to an irate user complaining that I had broken his program. I went back and saw that I had not noticed, or tested, the subroutine entrypoint into the same source file. Sure enough, I had broken it. I fixed it and life went on. But I have never forgotten that phone call. I’m still not perfect, but that irate voice echoing inside my head has saved me from making many similar, careless errors over the years since.
The aphorism that I coined from this case is “Untested code doesn’t work.”
Test your code. Find your own bugs; don’t make other folks find them. Avoid the irate voice!
Company