The term “Eating Your Own Dogfood” or “Dogfooding”, has spread throughout the tech industry in the past 20 years. Back on the farm we used a slightly different way to say the same thing (something about dogs and where they sleep) but it all means basically the same thing: it’s the idea of using the products we make to ensure that things actually work the way we say they do. The Aeris Android development project recently gave me a “no thank you bite” of my own.
When I sat down to pen the developer’s blog this week, I discovered the topic I had chosen was not as easy to write about as I assumed. My intention was to demonstrate creating a simple Android app using our Aeris Android SDK. As I dove in and began following the documentation we provide online, I noticed that while all the pieces are there, the process could be improved. For instance, our development team has migrated from using Eclipse to Android Studio, yet some of the documented steps still lean toward things that seem more suited for the former. An example of this is using local jar files rather than just compiling the aar bundle we make available via the Central Repository.
compile fileTree(include: ['*.jar'], dir: 'libs')
Even further confusing was the fact that we employ both methods of including a library at different places within the SDK. When I began detailing the whole process for my blog post, it felt a little awkward and I thought, “somebody should clean this up before I write about it”. Chatting with one of the other devs about my experience I realized I had stumbled onto a great object lesson for the use of dogfooding.
Besides the obvious benefit of making sure something actually works before shoving it in front of customers, there are many healthy side effects from actually using the things we create. I’m definitely not suggesting that we all dump the Test department and rely on dogfooding to ensure product reliability. However even in companies who employ a dedicated testing staff, there is still benefit in having designers and developers use their own products wherever it makes sense. It’s often difficult for the creator to imagine how an end-user might put their creation to use. I can’t remember the number of times I’ve received a bug report and either mumbled or shouted “Why on earth would anyone do that?”. It wasn’t until I really used our SDK as an end-user would — typing a mile on their keyboards if you will — that I experienced just how clunky the documentation felt. One bite of Aeris Android Alpo was enough to motivate me to want to improve the Android Studio experience for our developers.
By following the practice of using our own products, developers get to experience first hand the things that drive customers nuts. Without realizing it, this week I fell headfirst into the concept of eating my own dogfood. Using our SDK to write a blog post required me to dig deeper into and look differently at the code and documentation than I had previously, and that will ultimately result in a better overall experience for our Android developers. Speaking of that, be on the lookout for an update to the Aeris Android SDK with a cleaner implementation of our libraries and improved documentation in the near future! You can also check out the latest Aeris Android weather apps on the Google Play Store at Aeris Wear Weather and Aeris Pulse, or peruse our cool AerisWeather projects online.
Most of us wish that we could change the world around us when we run into things that drive us crazy. Eating our own dogfood gives us a the opportunity to actually make it so.
Bon Appetit and Happy Coding!