The value of dogfood

The value of dog food should not be underestimated, especially in a development context.

That sounds odd, but think of it this way: if you open a can of dog food and turn away in disgust, what makes you think your dog wants to eat it?

The relevance becomes quite important when you look at developments with the same mindset – if you don’t like using the system you’re developing, the odds are your users won’t either.

It should also be noted that at the same time, there is a sense of catalysis going on: if you see a fault in the system’s design or implementation when you’re using it yourself, there’s more chance it’ll be improved upon.

I know from my own experience that I find myself producing better things when I’m actively using them myself, so that instead of projecting the hypothetical use, and guessing how users will find it, I can actually try it out for real, because I’m not just someone who builds something, but I can actively use it the way other users use it. I certainly applied this process throughout development of SimpleDesk.

Thus, if you want to build something that others will use, you’ll probably be “dogfooding”, a.k.a. eating one’s own dogfood, to be able to assess it and make it usable.

There are, naturally, traps associated with doing this. Firstly, developer blindness: that situation where a developer knows how something is supposed to work and uses it with that in the back of their mind, including conscious and unconscious workarounds for aberrant (in the context of the system) behaviour.

I’ve seen that before, and more than once I’ve done it myself, where I’ve built something and the users misinterpreted how it was supposed to work, reporting something about it being buggy when in fact it wasn’t, it just wasn’t what was expected, even though it was precisely what I – as the developer – expected it to be.

The one example that springs to mind is SimpleDesk, actually. There’s a menu item for ‘Helpdesk’, and it typically includes a number after it to indicate how many active tickets there are that demand your attention. The number is a per user quirk, because it’s based on the number of tickets that apply to you to resolve, e.g. any tickets that you’ve opened that staff have replied to, and if you’re staff the number of tickets that users have opened and not yet had a staff reply, or tickets users have opened and the last reply was from a user.

But more than once I got asked what the number meant, and it always made sense to me – but not necessarily to others.

On a related note, there is also risk of combining things in unexpected ways, for example a regular customer might use two totally different systems in tandem, even if one of those two systems could happily take over and provide both sets of functionality. The customer, as it were, always has a choice over what they use and how they use it – while a zealously dogfooding developer will have that sense of tunnel vision, only seeing their own system in use. The only answer here is that developers should keep an eye out on other systems, actively trying to side-step their own blindness; to look at ways things might be combined, and with the mindset that what they are working on may not be used for the exact purpose for which it was designed.

The second is what has become known as ‘Not Invented Here’ syndrome. Larger establishments that have the technical and logistical resources to achieve things derive an ongoing self-imposed mission to create things, because they don’t feel comfortable with using something built by someone else.

Google does this a lot, instead of looking at other solutions, they’re more than content to throw a considerable amount of expertise at problems to create solutions, rather than looking elsewhere first. Additionally, you’ll notice that their mentality tends to be tunnel vision, rather than open minded (see comments relating to G+ and its naming policy, for example), a symptom of developer blindness.

Not Invented Here doesn’t have to be a bad thing, because it does encourage you to try new ideas rather than blindly copying what others have done in the same space (hey, innovate, not imitate, right?) but it does mean you also lose sight of the comments and feedback that others have received, you lose the accumulated knowledge of what works and what doesn’t, meaning you will make the same mistakes as others have done.