Eating Your Own Dogfood
Paw Prints: Writings of the maddog
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.
Place I work...The place I work writes and provides hosted SaaS software for non-profits and specifically aimed towards ministries, rescue missions and child sponsorship organizations.
For managing our clients, we use our software that we feed our clients. Sure there are a few tweaks and interface changes... as our system also has a built in ticket systems for problems, requests and other issues. But essentially our product acts the same with our clients/customers as they would see it managing clients/customers/constituents.
If we have a bug that typically affects us, its typically going to affect our customers. We fix them. Enhancement requests our team provides (including Sales) gives us a lot of feedback we might not normally get from our customers as some of them just pack-up and move on to yet another software provider, being unsatisfied with our product.
In the end, its a lot about making sure the system works first and foremost and then making sure it taste good... as I've often said about "Windows Users":
If all they have ever eaten is Dog Poo... How do they know what a great steak tastes like?
That is my driving motive to bring reliability to our systems and forced testing before its moved into production... though the automated testing isn't quite there yet in regards to pass/fail on to production, as we still have to queue it up manually.
Free Software for a Free World'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 would like to take the opportunity to make a little promotion of an awesome software called Blender and an even more amazing movie called Sintel.
Dog FoodMr. Hall,
I was on the other side of the fence from you -- as a field tech and customer of DEC product. Just so you know where I am coming from.
The period you speak of I was working some of my first IT jobs. Those days of the late '70's and 80's were also the time of the first great 'Unix Explosion' as I call it. There were no less than 35 variants out there for a while before I lost count. Unlike today where most of the Linux variants are derivatives of the 5 core Linux models, each of those 35 were sufficiently different at the kernel-shell level it was living hell for a tech like me in those times.
So when I would hit a client site and see the Digital label on the cabinet it was like coming home. Whether I was working on a PDP-11 or a VAX780 I knew my DCL skills and all those luscious scripts I have amassed _Just Worked_. Same with ole ATT SysV. SysV is the dowager that if you know how to tickle it right just keeps delivering the goods regardless of who did the install. From client site to client site I could just get it done. So I think fondly of DEC and even today could probably get more done on an old Alpha than having to futz with Windows7.
It is good to eat one's own dog food. But one should be careful that there are sufficient puppies with an interest in eating said dog food.
MSBuild is now just another GitHub project as Redmond continues its path to the light.
Malware could pass data and commands between disconnected computers without leaving a trace on the network.
New rules emphasize collegiality in coding.
Upstart lands in the dust bin as a new era begins for Linux.
HP's annual Cyber Risk report offers a bleak look at the state of IT.
But what do the big numbers really mean?
.NET Core execution engine is the basis for cross-platform .NET implementations.
The Xnote trojan hides itself on the target system and will launch a variety of attacks on command.
Spammers go low-volume, and 90% of IE browsers are unpatched.
Adobe scrambles to release patches for vulnerable Flash Player.