Eating your own dog food

I have no idea how generally known this saying is, but "eating your own dog food" in software development means to use your own products in your daily work. It is a good principle, because this way you will discover for yourself what does and what does not work well. Imagine that you found out that the majority of Apple employees prefer to work on a Windows PC - that would be very embarassing, wouldn't it?

The principle also applies to computer science. In the course of the years we try to teach our students some good practices: document your code, structure it well, use version control, and do a lot of testing. All of these are very unpopular because they take away time from the actual coding, which is the fun part. It all starts to make sense only when you start working on larger projects, especially in collaboration with others (always bad programmers who cannot be trusted with your code), and most especially when the project lasts for more than a few months and keeps getting modified and expanded. For a small code base, say a few thousand lines of code, it is at least possible to keep a mental record of the structure and design choices, but all that goes away when it grows beyond 100,000 lines or so.

There are also gruesome statistics about defect density, or average number of bugs per number of lines, which no-one will admit could possibly apply to their own code. Something like one bug per 100 lines of code (LOC) is not at all out of the ordinary. (Here I should say some appropriate words about how poorly defined this measure is and how careful one should be in interpreting the results: to name just one idiotic consequence, a good way to improve your defect density is to insert thousands of empty lines. Exact figures should be taken with buckets of salt, but the message I want to convey here is that software bugs abound.)

I am afraid that, as computer scientists, we ourselves seldom practice what we preach. As should be expected, a lot of research in computer science is supported by experiments that are supposed to demonstrate the value of the newly developed ideas. These experiments are almost always carried out using special tools written especially for that purpose. Alas, it would be naive to claim that we do any better here than our students. Documentation? No time, there's a paper to be written! Rigorous testing? Why, it's just a small tool, I'm a crack programmer, and anyway no-one besides myself is supposed to use it.

My own research concerns techniques for reducing errors in software. Admittedly there is a huge gap between the level on which I investigate this and the level on which my results would be directly helpful in industry, but nevertheless that is the context for my work, and also the context for a tool like GROOVE. Like everyone else, I'd like to claim that my dog food is mouthwatering, wonrderful stuff: once you've tasted it you will want nothing else. But in the meanwhile I am very much struggling with the same old problems. Code documentation: yes, a fair bit. Testing? Our standard test suite achieves less than 60% of line coverage. A PhD graduate of mine, Eduardo Zambon, recently ran some statistics on the GROOVE code base: we have close to 160,000 lines of code, which according to industry-standard practice should have required more than 40 man-years of development time. Not bad for an academic tool that has taken me and co-workers 10 years devoting only a small part of our time, but it also shows the magnitude of the maintenance problem we have been creating as we went along.

All of the above will give you some idea what I mean when I say that this programming stuff takes more time than I can afford. Fortunately the weather today was as bad as predicted, so I did not have to regret choosing to stay indoors and getting on with it. Only after 14:00 there were a few hours of daylight, a watery sun even. To escape from my apartment I did the Orbital Route again, a 15 km trip around York which was also the very first thing I tried after I had bought my bike. The circularity is appealing. Then it was back to the grind, with a frozen pizza in the way of dog food. At the time of writing, however, the simulteaneous need to also finish my last bottle of wine has probably made it wiser to stop coding, so as not to increase the defect density unnecessarily.