Every so often we hear that developers would do well to use the products they create. You probably know it as the not very appetising inducement to eat your own dog food. Do so and you will gain a better sense of what you’re doing it all for, and for whom. Even cat people can’t argue with the benefits. You don’t even have to enjoy the product; it can be a necessary evil like a tax return app. Be aware though that dogfooding is a mixed blessing, especially when the developers are a bit too passionate about the product. They are not your average users. Make them the sole masters of the product’s destiny and they will only build what tickles their fancy and over-engineer the hell out of it.
That’s why there’s so many WordPress code highlighting plugins: tools made by techies for other techies. As a hobby it makes perfect sense. You can be your own stakeholder, code whatever floats your boat and get kudos from your peers. You can scratch a personal itch and give back to the community, all the while doing what you like. You don’t even have to pretend you’re doing it for selfless reasons.
In the world of coding-for-pay a lot of software being produced is not very dogfoodable. Sure, on the one hand there’s tools for other developers and on the other we have software aimed at a general audience that you end up using yourself. But there’s way more in-house reporting, embedded and server-side stuff that the rest of the programming community buckles down to every day. With pleasure, mind you, because I don’t claim that being in the dogfood camp is by definition always more fun. I should think writing games is eminently dogfoodable and I imagine most developers are also keen gamers themselves, but the words relaxed, or sustainable pace do not spring to mind when I think of that industry. It’s not a recipe for success. The book Dreaming in Code (see previous post) about the doomed Chandler project dedicates a whole chapter to dogfooding.
Developers cannot always be the users of the code they write. Provided the technology is challenging and the team supportive they are usually fine with that. Yet one thing may be missing – something that the free WordPress plugin coders take for granted – and that is engagement with the end product. The more removed your coding assignment is from the end product, the more important it is to stimulate a connection between the development team and the end users, say when you are building some intricate RESTful API that queries multiple data sources and you have no involvement in the user interface.
Talk to end users. See how they use the product, ask questions, show an interest. Make it a point to always have them present at release demos. Whenever possible, go out and see where, how and by whom your software is used. In this context I cannot help thinking back to the unforgettable onboarding at the Port of Rotterdam when I joined their team in 2013. I was going to help build and maintain the crucial traffic control software and was taken on a tour to the heart of the control centre as well as a ride on a patrol boat where our software was used. We would regularly come back there whenever stakeholders needed to be involved in important UI changes. It really instilled a pride of ownership. One of the running gags after a successful release was saying: Als ik een haven had, zou ik het kopen. (If I had my own harbour, I would buy it).
