One of my favorite sayings has always been “You should eat your own dog food”. When applied to programming it quite simply means that you should use the code that you generate.

I started saying this many years ago when I noticed that the Unix product managers at Digital Equipment Corporation were not using Unix in their day to day work. They had Microsoft Windows systems on their desktop, and would often go over to VMS to use “EDT” (the VMS text editor) for doing “real editing”. One product manager at a very high level even admitted to “hating Unix”, and when asked why they were the product manager of a product they hated said “Where else could I make this much money?”

This attitude was not limited to product managers. Marketing people and management people at Digital often used either Microsoft or VMS to do their work. In some cases the people were working cross-platform, so they were using at least some of the products for which they were responsible, but in many cases they had moved from one project to another (particularly VMS to Unix) and they just continued to use the tools they used before.

Nor was engineering completely innocent. Digital released to our customers a very complex file system that we had developed for Digital Unix without ever having put that file system on any engineering production machines. When asked why we were not using this file system to do our own work, the incredulous answer came back “What if the file system lost data?” In other words, it was fine for the filesystem to lose data for our customers, but Digital’s engineering could not take that chance.

Sometimes this was taken to the state of being ridiculous. We were about to go to field test of a new installation subsystem. The distribution tapes had already been made and I settled down in my cubicle to install the field test software so I could use it. I found that the software would not install on my machine. Thinking that there was something unusual about my installation, I started looking at the installation script and realized that there was no possible way to get completely through the script from beginning to end. The logic in the installation script was faulty, and there was no possible way that it had executed correctly even one time. I went to the engineer and asked him if he had ever tested the software even one time. He assured me that he had, but then sheepishly admitted to making “one little change” before putting the code into the field test pool. I pointed out that his lack of testing had jeopardized the entire field test. If a customer can not even install the field test code, they quickly lose interest in helping you test it and make it better.

One of the reasons given for the writing of Free Software is to “scratch our own itch”, to create software the way we want it to work. If you then do not use it, how can you tell that the scratching satisfied the itch?

Of course there are cases where it is difficult for the programmer to use the software they write. For example, when the software is going to control a Boeing 747 aircraft, and the programmer has not yet been paid that week so they can not afford to go out and purchase a new plane to use in testing their software. Another case is when the programmer is working on software to control robots for brain surgeons.

Some of the best software I have seen from a functionality standpoint is software written by the same people who are going to be using it day after day. These people have a passion for having the software work “the way it should”, and usually the more people that create the software while also using it daily, the better it becomes.

Conversely, people who use Free Software to develop their Free Software development tools will, from time to time, become irritated because the software does not do exactly what they want it to do, and will then make the change to the code that allows that functionality. If all they use non-free software to do their development, then the Free Software may never do what they need.

Of course there are times where you may have no choice in using Free or non-free software. Free Software may offer no alternative to the use of non-free software. But those days are rapidly coming to a close.

In the area of multimedia, for instance. A few years ago making a video or doing multimedia work was the field of Apple’s computers. Today there are many good Free Software alternatives to non-free tools.

I was pleased, therefore, to see some people working for a Free Software company start up their own “Dog food Network” team, to encourage other people in the company to use the beta (and even alpha) copies of their software and to help the less technical in the company through various issues in using the new software. Who knows how many bugs and issues will be found by internal people using the code, before it gets to the customers? Or how many suggestions for improvements will come from the internal users?

I think it would be a good idea for other companies to form the same type of team.

Carpe Diem!