Eating your own dog food

In software development the phrase eating your own dog food means using the code that you write yourself.* This is usually aimed at improving usability and quality by having developers experience the same interface that the end-user does and thereby fix annoyances and bugs.

Without getting into the quality feedback side of "eating your own dog food" I'd like to bring up a related aspect that occurs to me from time to time.

I spend a lot of time writing and maintaining various spreadsheet modules on CPAN but outside of development I never actually use them. This is down to the fact that I work mainly in C and almost never have to deal (programmatically) with spreadsheets.

I wouldn't think that I am alone in this. I imagine that a lot of other CPAN authors find themselves initially writing or maintaining a module due to a short term requirement and then find themselves writing and maintaining the same module long after that requirement is forgotten.

The CPAN modules that I wrote and do use regularly are generally simpler and don't often require maintenance.

For example Pod::Simple::Wiki. This is very useful when switching departments/companies with different wikis. I just write my documentation in Pod format and then I can convert it to any wiki format that is required. I can also convert the Pod to other formats as needed.

Such as pod2cpanhtml which allows me to generate Html documents in the search.cpan.org format. This is also very useful for previewing and proof reading documentation prior to releasing it to CPAN.

A similar utility that I wrote is pod2epub for converting Pod documents to something that I can read on a mobile device.

And finally Data::Dumper::Perltidy allows me to use Data::Dumper style debugging with Perltidy formatting. That probably isn't a very common use case for anyone else but I find it very useful.

So, which of your modules/programs do you find yourself maintaining without using and which of them do you use on a regular basis?

--
John.

* In the dog food industry it means something slightly different.

Comment on Eating your own dog food

Replies are listed 'Best First'.
Re: Eating your own dog food by GrandFather (Saint) on Apr 05, 2011 at 11:15 UTC
It's interesting. I've contributed a small number of modules to CPAN and they very much fall into two camps: those I wrote to answer a short term need, and a couple that it turns out I keep coming back to. Of interest (to me anyway) is Video::Dumper::QuickTime which has only recently fallen into the second camp by virtue of a work mate prompting me to dig it out to solve a rather different problem than first envisaged. The module facilitates pulling apart movie files. It turns out QuickTime is something of a misnomer as it actually works for many of the standard movie file formats. We needed to investigate how subtitle tracks were being managed for a tool we were writing and Video::Dumper::QuickTime turned out to be just the tool to do that. Then we found we needed to make a minor post-processing edit to the movie file, and it further turned out that a trivial class derived from the module's class did what we needed! To say I was a somewhat pleased may perhaps have been understating the case a little! The module that I use all the time is Win32::MSI::HighLevel which provides a wrapper around the Windows MSI installer API. The module is a vital part of our automated build system and has had a reasonable amount of attention. I find it pleasing that other people have reported bugs in it. At least that means that half a dozen other people have at least tried to use it hard enough to encounter bugs! I'm slightly worried by the fact that some of those bugs have been reported by big military manufacturers and space agencies. The last "dog food" module is one that I have "in production". Win32::PEFile was written initially to provide access to version information in "Portable Executable" files - Windows .exe and .dll files and other files of that format. In some future iteration of the production system that uses it I need to be able to edit a PE file, at least to the extent of adding a cryptographic signature to it. What makes that an interesting exercise is that the signing has to be done on a Linux box for a Windows executable file. The module is pure Perl, cross-platform and endien agnostic (at least in principle - I've not got a big endien machine to test it on). The rest of my CPAN modules are very much of the short term interest sort. Some of them I've intended to go back and have a play with because they were fun, but unless someone files a bug report or feature request for them, I probably won't get around to it. I do find though, that even for the small interest modules I've written and contributed to CPAN, the payback of getting a few other people using the modules and reporting bugs (along with fixes in a few cases) is quite worth while and does justify the effort of a little polishing and placing them in CPAN (even in the eyes of the boss for, as it happens, all the "dog food" ones). True laziness is hard work	[reply]
Re^2: Eating your own dog food by sundialsvc4 (Abbot) on Apr 05, 2011 at 17:54 UTC
I’m slightly worried by the fact that some of those bugs have been reported by big military manufacturers and space agencies. I likewise briefly wondered why the Norwegian Department of Defense bought `=CLASSIFIED=` copies of a product that I wrote. (But I sold it to them anyway.)
Re^3: Eating your own dog food by cavac (Parson) on Apr 05, 2011 at 21:28 UTC
Yeah, i'm in a similar (but yet a bit different) situation: I work for a big automotive supplier, helping to build 4x4 vehicles. So, in effect, my boss and my end customers pay me to help them pollute the planet. Now, i myself don't even own a car anymore - i decided to ride a bike and use public transportation for longer trips. (Talk about using your own products...) Well, from what i see, all we can do is to promote responsible use of our products. But ultimately, what the customer does with that products is out of our control... Even if the brick manufacturer makes bricks so customers can build houses, the customer can still use that brick to kill someone. What can the brick manufacturer do about it... except to continue making bricks and putting food on the table for his family. I think that is the true price of having a free, open market, where the only thing that counts is shareholder value. Don't use '#ff0000': use Acme::AutoColor; my $redcolor = RED(); All colors subject to change without notice.	[reply]
Re^4: Eating your own dog food by sundialsvc4 (Abbot) on Apr 05, 2011 at 21:56 UTC
Re^5: Eating your own dog food by cavac (Parson) on Apr 05, 2011 at 22:45 UTC
Re^2: Eating your own dog food by Jenda (Abbot) on Apr 07, 2011 at 13:38 UTC
The effort you put into polishing the code and updating the docs before a planned release to CPAN is worth while even if in the end you do not release the module. If you know someone else will look at your code and read your docs, you generally do a better job. Especially with the docs. Jenda Enoch was right! Enjoy the last years of Rome.	[reply]
Re: Eating your own dog food by Tux (Canon) on Apr 05, 2011 at 14:12 UTC
I completely agree, and even posted this not too long ago. Very related to your post. App::tkiv - use this on a daily bases Config::Perl::V - used by something else in the background. Almost twice a week. I hope it will be used a lot more after the upcoming QAH. Data::Peek - use this countless times each day :) DBD::CSV - use it once a month, but test it more than that. DBD::Unify - use it on a daily basis, and I hope to be able to abandon it within the next year. GSM::Gnokii - unreleased. See here why. Used several times a week. Spreadsheet::Read - used inside other tools. Probably several times a week. Test::Smoke::Metabase - used once a week but hopefully more after the QAH. In development. Text::CSV_XS - used very very often. Probably over ten times a day. Text::OutputFilter - no idea how often this is used (by my colleagues and or our customers). Tie::Hash::DBD - used by our customers. Probably twice per year. Tk::Clock - is on all my desktops. All day, every day. VCS::SCCS - never again, I hope :) I used it to convert SCCS repo's to git. Enjoy, Have FUN! H.Merijn	[reply]
Re: Eating your own dog food by idsfa (Vicar) on Apr 06, 2011 at 02:25 UTC
Our company prefers to "Drink our own champagne" The intelligent reader will judge for himself. Without examining the facts fully and fairly, there is no way of knowing whether vox populi is really vox dei, or merely vox asinorum. — Cyrus H. Gordon	[reply]
Re: Eating your own dog food by cavac (Parson) on Apr 05, 2011 at 21:33 UTC
Well, except for a few Acme:: modules i took over maintenance, the only thing i released so far is my Maplat framework. The release is still a bit incomplete, because development started out as a closed source project - but i'm getting there (hopefully before the end of the year). And yes, i'm using it on a daily bases. Have to... some of my admin tools as well as some of my most critical services run on it. So, yeah, bugs get fixed quite fast... most of them, anyway. Don't use '#ff0000': use Acme::AutoColor; my $redcolor = RED(); All colors subject to change without notice.	[reply]