For the uninitiated, I, nor any other developer, actually eats dog food (not that I know of anyway). The term “Dogfooding” simply refers to the process of using your own tool to build your own tool. Wikipedia describes it as “a slang term used to reference a scenario in which a company uses its own product to test and promote the product”.

So in the case of wProject, I used wProject to manage the development of wProject.

This approach comes with some obvious benefits, with some that come to mind being…

  • You’re likely to spot issues sooner while using your product day to day
  • Your experience will be closer to what your customers experience
  • Constant usage of the product may reveal UX or workflow issues you never considered
  • Feedback from the team and stake holders can offer a different perspective than your customers
  • Constant usage may reveal critical/security issues that customers might not have a chance to discover
  • If it’s known that you use your own product, the market will have more confidence in it

…and I’m certain there are more I can’t think of right now.

It’s important to understand that while dogfooding will make you and the team more intimate with your product, and by default result in a better product, it’s by no means a substitute for rigorous feature-by-feature testing.

You still have to test thoroughly, get feedback from beta testers (if you have any at your disposal), and test again ad-nauseum. Dogfooding is simply another tool in your arsenal to help deliver a better product.

No software is perfect, and no amount of testing can 100% guarantee you won’t release a bug-free product (but you might get close). Many apps – including wProject – are released with unintentional bugs that aren’t discovered until later down the track when a customer uses your product in ways you never expected or intended, despite your best efforts.