Eating Your Own Dog Food.

I’m a big fan of using the services you create while you create them, popularised by Microsoft as ‘eating your own dog food’.

Developing services this way improves many aspects of a project and I include it in my tips for improving the way we measure progress in a project.  I have another post that drills into the technique for a Desktop Infrastructure Project.

Joel, writes up an interesting example of NOT eating your own dog food, (i.e. using the IT solutions you are developing yourself), until it was almost too late:

Eating your own dog food is the quaint name that we in the computer industry give to the process of actually using your own product. I had forgotten how well it worked, until a month ago, I took home a build of CityDesk (thinking it was about 3 weeks from shipping) and tried to build a site with it. Phew! There were a few bugs that literally made it impossible for me to proceed, so I had to fix those before I could even continue. All the testing we did, meticulously pulling down every menu and seeing if it worked right, didn’t uncover the showstoppers that made it impossible to do what the product was intended to allow. Trying to use the product, as a customer would, found these showstoppers in a minute.

And not just those. As I worked, not even exercising the features, just quietly trying to build a simple site, I found 45 bugs on one Sunday afternoon. And I am a lazy man, I couldn’t have spent more than 2 hours on this. I didn’t even try anything but the most basic functionality of the product.

Monday morning, when I got in to work, I gathered the team in the kitchen. I told them about the 45 bugs. (To be fair, many of these bugs weren’t actual defects but simply things that were not as convenient as they should have been). Then I suggested that everybody build at least one serious site using CityDesk to smoke out more bugs. That’s what is meant by eating your own dog food.

This is just SO IMPORTANT, as an architect of enterprise infrastructures I get really frustrated when I try and use them, if I did not get that frustrated I would not be motivated to fix the issues, in fact I would not even know they existed.  In my ideal project the project must use the environment its creating, even if it has to distort its processes a bit to fit the product, its key it uses it if at all possible.  Its likely to be a real pain to the project to do this because it means the project is running on/depending on something that a bit flaky but its worth it.

As an architect its especially important because it allows you to validate that your concept is indeed being implemented and that your concept is correct, which it never is!  If you don’t use it I don’t see much chance of either of these being achieved.

I really dread to think what a solution would look like if it didn’t go through this process, if the only way to define what something looked like was a specification, and the prayer that some how the author of the specification and the 50-100 people who developed the solution from it actually were able to maintain not just conceptual integrity but also usability!

The picture is of the River Humber, close to this river is the office where I first introduced the idea of eating our own dogfood and it worked very well.  This is long before Microsoft used it, certainly over 20 years ago.